VistApedia - User contributions [en]

Main Page

2011-11-11T12:31:55Z

Butch: /* Versions of VistA */

= Vistapedia =

== What is VistA? ==
'''[[VistA]]''' is a public domain [http://en.wikipedia.org/wiki/Electronic_health_record electronic health record] programmed by federal employees working for the [http://www.va.gov US Department of Veterans Affairs] (previously the [http://en.wikipedia.org/wiki/United_States_Department_of_Veterans_Affairs Veterans Administration]) over the past several decades. For more info, see [[VistA|this page]].

== What is RPMS? ==
[http://www.ehr.ihs.gov/ RPMS] is a public domain electronic health record that is used by the [http://en.wikipedia.org/wiki/Indian_Health_Service Indian Health Service] (IHS). Prior to the 1980s it used a different architecture from VistA, but since the 80's it has shared a large amount of its architecture with VistA. For more info, see [[RPMS|this page]].

== What is Vistapedia? ==
Vistapedia is a wiki for several varieties of the [http://en.wikipedia.org/wiki/Public_domain public domain] versions of VistA and [http://www.ehr.ihs.gov/ RPMS]. Information about the integrated VistA installer called [[Astronaut_VistA|Astronaut]] is also contained within these pages.

This wiki covers installation, configuration, and usage of these VistA derivatives. It also serves as an introduction to the [[VistA Documentation Library]] for everyone outside the VA. In addition, current events, development advances, and other news about the flavors of VistA are posted here.

This wiki runs the same [http://www.mediawiki.org software] as [http://www.wikipedia.com/ Wikipedia].

----

=== Versions of VistA ===
There are several versions of VistA that are used outside of the VA. (See [[Which VistA|this page]] for some introductory information regarding aspects of the different versions.)

* [[How to Get WorldVistA EHR|WorldVistA EHR]] ([http://www.opensource.org/licenses/gpl-2.0.php GPL] licensed) ([http://worldvista.org Home]) ([http://worldvista.org/Software_Download Download]) ([[WorldVista|Installation]]) ([[Astronaut_VistA#Astronaut_WorldVistA_installers|Astronaut installer]])

* [[OpenVista]] ([http://www.opensource.org/licenses/agpl-v3.html AGPL] licensed) ([http://medsphere.org Home]) ([http://medsphere.org/download Download]) ([[OpenVista|Installation]]) ([[Astronaut_VistA#Astronaut_OpenVistA_installers|Astronaut installer]])

* [[vxVista]] ([http://www.opensource.org/licenses/eclipse-1.0.php EPL] licensed) (requires a proprietary Cache database) ([http://www.docstorsys.com/dss-vxOpenSource.html Home]) ([http://www.vxvista.org/display/vxv/vxVistA+Download Download])
** vxVista can now be ported to run on the FIS GT.M platform as well. The instructions can be found [http://www.seaislandsystems.com/vxVistA/HowToPort.html here] (external link).

* FOIA Vista ([http://en.wikipedia.org/wiki/Public_domain public domain] under [http://en.wikipedia.org/wiki/Freedom_of_Information_Act_%28United_States%29 FOIA]) ([http://www.va.gov/vista_monograph/ Home]) ([ftp://ftp.va.gov/Vista/Software/VISTA_FOIA_ZIPS/ Download])

(Other versions such as da Vinci Vista, VOE Vista, and Hui Vista no longer exist or are no longer maintained.)

== Detailed Information ==

*[[How does VistA work]]? -- basic information about VistA's components.

*[[Where do I Start]]? -- Start here.

*[http://www.vistapedia.net/index.php?title=Category:FAQ FAQ] -- common Questions about VistA.

*[[Usage]] -- start using VistA once it is successfully installed

*[[Special:Popularpages|Popular pages]] -- frequently viewed pages in this wiki.

*[http://www.vistapedia.net/index.php?title=Special:Categories Categories] -- good for browsing.

*[[Special:Specialpages|Special pages]] -- a form of Table of Contents for this wiki.

*[[VistA Community Challenges]] -- the issues we're trying to solve currently.

*[[Flydoc pages|Flydoc's documentation]] -- training docs from a real-world implementation

=== Meaningful Use ===
* [[Meaningful_Use_Stage_One_Final_Rule|Meaningful Use]] -- criteria and resources for Stage 1 (Final Rule)

* [[MU_Stage_One_Standards|Meaningful Use Stage One Standards]]

* [[Meaningful_Use_Stage_One_Final_Rule_Analysis|Meaningful Use Analysis, Commentary and Presentations]]

*[[Meaningful Use (WG6)|Meaningful Use (Interim Rule)]] -- analysis of the EHR requirements for Stage 1 (Interim Rule) to qualify for stimulus funds from the US government.

* [[EP_Measure_Specifications_Overview|Quality Measure Specifications (for both EP & EH)]]

* [[NIST_Test_Patients|NIST Test Patient Data]]

== Topics in active development ==
*[[ePrescribing]]

*[[Health Information Exchange]]

*[[Scanned_Documents|Working with Scanned Documents and Images]]

*[[Certification]]

*[[Training centers]]

*[[Practice_Management_System|Practice Management Systems]]

*[[Web Interfaces|Web-based Interfaces]]

== Current events ==
* [[Current events]] -- The 21st VistA Community Meeting was held June 8-11 in Fairfax Virginia.

== Other content ==

* [[Old_Main|Old Main Page]]
* [[Installation_Overview|Installation Overview (old)]]
* [[Licensing|Licensing issues]]
* [https://medsphere.org/docs/DOC-1195 Other client modules (page on medsphere.org)]
* [[User setups]] -- specific success (or failure) stories with various configurations provided by various users and adopters
* [[SHabiel_Pages| Sam's Pages]] Sam's Pages for various config stuff in VISTA.
* [[Broker_help|Broker Help]]

== Other resources ==
* [http://66.206.177.92/conference_presentations WorldVistA conference presentations]

* VistA enthusiasts and developers connect through [http://www.google.com/group/hardhats the Hardhats Google Group]. For more info, email: info at worldvista dot org.


To get access to Vistapedia, contact David Whitten ( whitten at worldvista.org ) through
an e-mail, or phone 713 870 3834 to get an account. Please send a contact telephone number with your e-mail, and/or have an e-mail address ready when you call. (I need both.) Please decide on your preferred User name and send it as well. We have provided a [[User Status|page]] for new users and their current status. Thank you.

Main Page

2011-11-06T05:42:44Z

Butch: Removed maintenance notice

= Vistapedia =

== What is VistA? ==
'''[[VistA]]''' is a public domain [http://en.wikipedia.org/wiki/Electronic_health_record electronic health record] programmed by federal employees working for the [http://www.va.gov US Department of Veterans Affairs] (previously the [http://en.wikipedia.org/wiki/United_States_Department_of_Veterans_Affairs Veterans Administration]) over the past several decades. For more info, see [[VistA|this page]].

== What is RPMS? ==
[http://www.ehr.ihs.gov/ RPMS] is a public domain electronic health record that is used by the [http://en.wikipedia.org/wiki/Indian_Health_Service Indian Health Service] (IHS). Prior to the 1980s it used a different architecture from VistA, but since the 80's it has shared a large amount of its architecture with VistA. For more info, see [[RPMS|this page]].

== What is Vistapedia? ==
Vistapedia is a wiki for several varieties of the [http://en.wikipedia.org/wiki/Public_domain public domain] versions of VistA and [http://www.ehr.ihs.gov/ RPMS]. Information about the integrated VistA installer called [[Astronaut_VistA|Astronaut]] is also contained within these pages.

This wiki covers installation, configuration, and usage of these VistA derivatives. It also serves as an introduction to the [[VistA Documentation Library]] for everyone outside the VA. In addition, current events, development advances, and other news about the flavors of VistA are posted here.

This wiki runs the same [http://www.mediawiki.org software] as [http://www.wikipedia.com/ Wikipedia].

----

=== Versions of VistA ===
There are several versions of VistA that are used outside of the VA. (See [[Which VistA|this page]] for some introductory information regarding aspects of the different versions.)

* [[How to Get WorldVistA EHR|WorldVistA EHR]] ([http://www.opensource.org/licenses/gpl-2.0.php GPL] licensed) ([http://worldvista.org Home]) ([http://worldvista.org/Software_Download Download]) ([[WorldVista|Installation]]) ([[Astronaut_VistA#Astronaut_WorldVistA_installers|Astronaut installer]])

* [[OpenVista]] ([http://www.opensource.org/licenses/agpl-v3.html AGPL] licensed) ([http://medsphere.org Home]) ([http://medsphere.org/download Download]) ([[OpenVista|Installation]]) ([[Astronaut_VistA#Astronaut_OpenVistA_installers|Astronaut installer]])

* [[vxVista]] ([http://www.opensource.org/licenses/eclipse-1.0.php EPL] licensed) (requires a proprietary Cache database) ([http://www.docstorsys.com/dss-vxOpenSource.html Home]) ([http://www.vxvista.org/display/vxv/vxVistA+Download Download])

* FOIA Vista ([http://en.wikipedia.org/wiki/Public_domain public domain] under [http://en.wikipedia.org/wiki/Freedom_of_Information_Act_%28United_States%29 FOIA]) ([http://www.va.gov/vista_monograph/ Home]) ([ftp://ftp.va.gov/Vista/Software/VISTA_FOIA_ZIPS/ Download])

(Other versions such as da Vinci Vista, VOE Vista, and Hui Vista no longer exist or are no longer maintained.)

== Detailed Information ==

*[[How does VistA work]]? -- basic information about VistA's components.

*[[Where do I Start]]? -- Start here.

*[http://www.vistapedia.net/index.php?title=Category:FAQ FAQ] -- common Questions about VistA.

*[[Usage]] -- start using VistA once it is successfully installed

*[[Special:Popularpages|Popular pages]] -- frequently viewed pages in this wiki.

*[http://www.vistapedia.net/index.php?title=Special:Categories Categories] -- good for browsing.

*[[Special:Specialpages|Special pages]] -- a form of Table of Contents for this wiki.

*[[VistA Community Challenges]] -- the issues we're trying to solve currently.

*[[Flydoc pages|Flydoc's documentation]] -- training docs from a real-world implementation

=== Meaningful Use ===
* [[Meaningful_Use_Stage_One_Final_Rule|Meaningful Use]] -- criteria and resources for Stage 1 (Final Rule)

* [[MU_Stage_One_Standards|Meaningful Use Stage One Standards]]

* [[Meaningful_Use_Stage_One_Final_Rule_Analysis|Meaningful Use Analysis, Commentary and Presentations]]

*[[Meaningful Use (WG6)|Meaningful Use (Interim Rule)]] -- analysis of the EHR requirements for Stage 1 (Interim Rule) to qualify for stimulus funds from the US government.

* [[EP_Measure_Specifications_Overview|Quality Measure Specifications (for both EP & EH)]]

* [[NIST_Test_Patients|NIST Test Patient Data]]

== Topics in active development ==
*[[ePrescribing]]

*[[Health Information Exchange]]

*[[Scanned_Documents|Working with Scanned Documents and Images]]

*[[Certification]]

*[[Training centers]]

*[[Practice_Management_System|Practice Management Systems]]

*[[Web Interfaces|Web-based Interfaces]]

== Current events ==
* [[Current events]] -- The 21st VistA Community Meeting was held June 8-11 in Fairfax Virginia.

== Other content ==

* [[Old_Main|Old Main Page]]
* [[Installation_Overview|Installation Overview (old)]]
* [[Licensing|Licensing issues]]
* [https://medsphere.org/docs/DOC-1195 Other client modules (page on medsphere.org)]
* [[User setups]] -- specific success (or failure) stories with various configurations provided by various users and adopters
* [[SHabiel_Pages| Sam's Pages]] Sam's Pages for various config stuff in VISTA.
* [[Broker_help|Broker Help]]

== Other resources ==
* [http://66.206.177.92/conference_presentations WorldVistA conference presentations]

* VistA enthusiasts and developers connect through [http://www.google.com/group/hardhats the Hardhats Google Group]. For more info, email: info at worldvista dot org.


To get access to Vistapedia, contact David Whitten ( whitten at worldvista.org ) through
an e-mail, or phone 713 870 3834 to get an account. Please send a contact telephone number with your e-mail, and/or have an e-mail address ready when you call. (I need both.) Please decide on your preferred User name and send it as well. We have provided a [[User Status|page]] for new users and their current status. Thank you.

User:Butch

2011-11-06T04:11:07Z

Butch:

I have several years experience working with UNIX/Linux and their various flavors (Solaris 10/11, OpenSolaris, Illumos, OpenIndiana, Redhat, CentOS).

Main Page

2011-11-06T04:06:10Z

Butch:

= Maintenance Notice =
Vistapedia.net will be undergoing maintenance on November 5th 2011, between the hours of 22:00 and 02:00 EST. During this time logins will be unavailable, however the site should remain viewable throughout the maintenance process. We apologize for any inconvenience this may cause and will endeavor to return vistapedia.net to normal operation as quickly as possible.
= Vistapedia =

== What is VistA? ==
'''[[VistA]]''' is a public domain [http://en.wikipedia.org/wiki/Electronic_health_record electronic health record] programmed by federal employees working for the [http://www.va.gov US Department of Veterans Affairs] (previously the [http://en.wikipedia.org/wiki/United_States_Department_of_Veterans_Affairs Veterans Administration]) over the past several decades. For more info, see [[VistA|this page]].

== What is RPMS? ==
[http://www.ehr.ihs.gov/ RPMS] is a public domain electronic health record that is used by the [http://en.wikipedia.org/wiki/Indian_Health_Service Indian Health Service] (IHS). Prior to the 1980s it used a different architecture from VistA, but since the 80's it has shared a large amount of its architecture with VistA. For more info, see [[RPMS|this page]].

== What is Vistapedia? ==
Vistapedia is a wiki for several varieties of the [http://en.wikipedia.org/wiki/Public_domain public domain] versions of VistA and [http://www.ehr.ihs.gov/ RPMS]. Information about the integrated VistA installer called [[Astronaut_VistA|Astronaut]] is also contained within these pages.

This wiki covers installation, configuration, and usage of these VistA derivatives. It also serves as an introduction to the [[VistA Documentation Library]] for everyone outside the VA. In addition, current events, development advances, and other news about the flavors of VistA are posted here.

This wiki runs the same [http://www.mediawiki.org software] as [http://www.wikipedia.com/ Wikipedia].

----

=== Versions of VistA ===
There are several versions of VistA that are used outside of the VA. (See [[Which VistA|this page]] for some introductory information regarding aspects of the different versions.)

* [[How to Get WorldVistA EHR|WorldVistA EHR]] ([http://www.opensource.org/licenses/gpl-2.0.php GPL] licensed) ([http://worldvista.org Home]) ([http://worldvista.org/Software_Download Download]) ([[WorldVista|Installation]]) ([[Astronaut_VistA#Astronaut_WorldVistA_installers|Astronaut installer]])

* [[OpenVista]] ([http://www.opensource.org/licenses/agpl-v3.html AGPL] licensed) ([http://medsphere.org Home]) ([http://medsphere.org/download Download]) ([[OpenVista|Installation]]) ([[Astronaut_VistA#Astronaut_OpenVistA_installers|Astronaut installer]])

* [[vxVista]] ([http://www.opensource.org/licenses/eclipse-1.0.php EPL] licensed) (requires a proprietary Cache database) ([http://www.docstorsys.com/dss-vxOpenSource.html Home]) ([http://www.vxvista.org/display/vxv/vxVistA+Download Download])

* FOIA Vista ([http://en.wikipedia.org/wiki/Public_domain public domain] under [http://en.wikipedia.org/wiki/Freedom_of_Information_Act_%28United_States%29 FOIA]) ([http://www.va.gov/vista_monograph/ Home]) ([ftp://ftp.va.gov/Vista/Software/VISTA_FOIA_ZIPS/ Download])

(Other versions such as da Vinci Vista, VOE Vista, and Hui Vista no longer exist or are no longer maintained.)

== Detailed Information ==

*[[How does VistA work]]? -- basic information about VistA's components.

*[[Where do I Start]]? -- Start here.

*[http://www.vistapedia.net/index.php?title=Category:FAQ FAQ] -- common Questions about VistA.

*[[Usage]] -- start using VistA once it is successfully installed

*[[Special:Popularpages|Popular pages]] -- frequently viewed pages in this wiki.

*[http://www.vistapedia.net/index.php?title=Special:Categories Categories] -- good for browsing.

*[[Special:Specialpages|Special pages]] -- a form of Table of Contents for this wiki.

*[[VistA Community Challenges]] -- the issues we're trying to solve currently.

*[[Flydoc pages|Flydoc's documentation]] -- training docs from a real-world implementation

=== Meaningful Use ===
* [[Meaningful_Use_Stage_One_Final_Rule|Meaningful Use]] -- criteria and resources for Stage 1 (Final Rule)

* [[MU_Stage_One_Standards|Meaningful Use Stage One Standards]]

* [[Meaningful_Use_Stage_One_Final_Rule_Analysis|Meaningful Use Analysis, Commentary and Presentations]]

*[[Meaningful Use (WG6)|Meaningful Use (Interim Rule)]] -- analysis of the EHR requirements for Stage 1 (Interim Rule) to qualify for stimulus funds from the US government.

* [[EP_Measure_Specifications_Overview|Quality Measure Specifications (for both EP & EH)]]

* [[NIST_Test_Patients|NIST Test Patient Data]]

== Topics in active development ==
*[[ePrescribing]]

*[[Health Information Exchange]]

*[[Scanned_Documents|Working with Scanned Documents and Images]]

*[[Certification]]

*[[Training centers]]

*[[Practice_Management_System|Practice Management Systems]]

*[[Web Interfaces|Web-based Interfaces]]

== Current events ==
* [[Current events]] -- The 21st VistA Community Meeting was held June 8-11 in Fairfax Virginia.

== Other content ==

* [[Old_Main|Old Main Page]]
* [[Installation_Overview|Installation Overview (old)]]
* [[Licensing|Licensing issues]]
* [https://medsphere.org/docs/DOC-1195 Other client modules (page on medsphere.org)]
* [[User setups]] -- specific success (or failure) stories with various configurations provided by various users and adopters
* [[SHabiel_Pages| Sam's Pages]] Sam's Pages for various config stuff in VISTA.
* [[Broker_help|Broker Help]]

== Other resources ==
* [http://66.206.177.92/conference_presentations WorldVistA conference presentations]

* VistA enthusiasts and developers connect through [http://www.google.com/group/hardhats the Hardhats Google Group]. For more info, email: info at worldvista dot org.


To get access to Vistapedia, contact David Whitten ( whitten at worldvista.org ) through
an e-mail, or phone 713 870 3834 to get an account. Please send a contact telephone number with your e-mail, and/or have an e-mail address ready when you call. (I need both.) Please decide on your preferred User name and send it as well. We have provided a [[User Status|page]] for new users and their current status. Thank you.

MediaWiki:Sidebar

2011-11-06T03:47:27Z

Butch:

MediaWiki:Sidebar

2011-11-06T03:46:30Z

Main Page

2011-11-01T22:40:46Z

Butch: Maintenance notice

= Vistapedia =
= Maintenance Notice =
Vistapedia.net will be undergoing maintenance on November 5th 2011, between the hours of 22:00 and 02:00 EST. During this time logins will be unavailable, however the site should remain viewable throughout the maintenance process. We apologize for any inconvenience this may cause and will endeavor to return vistapedia.net to normal operation as quickly as possible.
== What is VistA? ==
'''[[VistA]]''' is a public domain [http://en.wikipedia.org/wiki/Electronic_health_record electronic health record] programmed by federal employees working for the [http://www.va.gov US Department of Veterans Affairs] (previously the [http://en.wikipedia.org/wiki/United_States_Department_of_Veterans_Affairs Veterans Administration]) over the past several decades. For more info, see [[VistA|this page]].

== What is RPMS? ==
[http://www.ehr.ihs.gov/ RPMS] is a public domain electronic health record that is used by the [http://en.wikipedia.org/wiki/Indian_Health_Service Indian Health Service] (IHS). Prior to the 1980s it used a different architecture from VistA, but since the 80's it has shared a large amount of its architecture with VistA. For more info, see [[RPMS|this page]].

== What is Vistapedia? ==
Vistapedia is a wiki for several varieties of the [http://en.wikipedia.org/wiki/Public_domain public domain] versions of VistA and [http://www.ehr.ihs.gov/ RPMS]. Information about the integrated VistA installer called [[Astronaut_VistA|Astronaut]] is also contained within these pages.

This wiki covers installation, configuration, and usage of these VistA derivatives. It also serves as an introduction to the [[VistA Documentation Library]] for everyone outside the VA. In addition, current events, development advances, and other news about the flavors of VistA are posted here.

This wiki runs the same [http://www.mediawiki.org software] as [http://www.wikipedia.com/ Wikipedia].

----

=== Versions of VistA ===
There are several versions of VistA that are used outside of the VA. (See [[Which VistA|this page]] for some introductory information regarding aspects of the different versions.)

* [[How to Get WorldVistA EHR|WorldVistA EHR]] ([http://www.opensource.org/licenses/gpl-2.0.php GPL] licensed) ([http://worldvista.org Home]) ([http://worldvista.org/Software_Download Download]) ([[WorldVista|Installation]]) ([[Astronaut_VistA#Astronaut_WorldVistA_installers|Astronaut installer]])

* [[OpenVista]] ([http://www.opensource.org/licenses/agpl-v3.html AGPL] licensed) ([http://medsphere.org Home]) ([http://medsphere.org/download Download]) ([[OpenVista|Installation]]) ([[Astronaut_VistA#Astronaut_OpenVistA_installers|Astronaut installer]])

* [[vxVista]] ([http://www.opensource.org/licenses/eclipse-1.0.php EPL] licensed) (requires a proprietary Cache database) ([http://www.docstorsys.com/dss-vxOpenSource.html Home]) ([http://www.vxvista.org/display/vxv/vxVistA+Download Download])

* FOIA Vista ([http://en.wikipedia.org/wiki/Public_domain public domain] under [http://en.wikipedia.org/wiki/Freedom_of_Information_Act_%28United_States%29 FOIA]) ([http://www.va.gov/vista_monograph/ Home]) ([ftp://ftp.va.gov/Vista/Software/VISTA_FOIA_ZIPS/ Download])

(Other versions such as da Vinci Vista, VOE Vista, and Hui Vista no longer exist or are no longer maintained.)

== Detailed Information ==

*[[How does VistA work]]? -- basic information about VistA's components.

*[[Where do I Start]]? -- Start here.

*[http://www.vistapedia.net/index.php?title=Category:FAQ FAQ] -- common Questions about VistA.

*[[Usage]] -- start using VistA once it is successfully installed

*[[Special:Popularpages|Popular pages]] -- frequently viewed pages in this wiki.

*[http://www.vistapedia.net/index.php?title=Special:Categories Categories] -- good for browsing.

*[[Special:Specialpages|Special pages]] -- a form of Table of Contents for this wiki.

*[[VistA Community Challenges]] -- the issues we're trying to solve currently.

*[[Flydoc pages|Flydoc's documentation]] -- training docs from a real-world implementation

=== Meaningful Use ===
* [[Meaningful_Use_Stage_One_Final_Rule|Meaningful Use]] -- criteria and resources for Stage 1 (Final Rule)

* [[MU_Stage_One_Standards|Meaningful Use Stage One Standards]]

* [[Meaningful_Use_Stage_One_Final_Rule_Analysis|Meaningful Use Analysis, Commentary and Presentations]]

*[[Meaningful Use (WG6)|Meaningful Use (Interim Rule)]] -- analysis of the EHR requirements for Stage 1 (Interim Rule) to qualify for stimulus funds from the US government.

* [[EP_Measure_Specifications_Overview|Quality Measure Specifications (for both EP & EH)]]

* [[NIST_Test_Patients|NIST Test Patient Data]]

== Topics in active development ==
*[[ePrescribing]]

*[[Health Information Exchange]]

*[[Scanned_Documents|Working with Scanned Documents and Images]]

*[[Certification]]

*[[Training centers]]

*[[Practice_Management_System|Practice Management Systems]]

*[[Web Interfaces|Web-based Interfaces]]

== Current events ==
* [[Current events]] -- The 21st VistA Community Meeting was held June 8-11 in Fairfax Virginia.

== Other content ==

* [[Old_Main|Old Main Page]]
* [[Installation_Overview|Installation Overview (old)]]
* [[Licensing|Licensing issues]]
* [https://medsphere.org/docs/DOC-1195 Other client modules (page on medsphere.org)]
* [[User setups]] -- specific success (or failure) stories with various configurations provided by various users and adopters
* [[SHabiel_Pages| Sam's Pages]] Sam's Pages for various config stuff in VISTA.
* [[Broker_help|Broker Help]]

== Other resources ==
* [http://66.206.177.92/conference_presentations WorldVistA conference presentations]

* VistA enthusiasts and developers connect through [http://www.google.com/group/hardhats the Hardhats Google Group]. For more info, email: info at worldvista dot org.


To get access to Vistapedia, contact David Whitten ( whitten at worldvista.org ) through
an e-mail, or phone 713 870 3834 to get an account. Please send a contact telephone number with your e-mail, and/or have an e-mail address ready when you call. (I need both.) Please decide on your preferred User name and send it as well. We have provided a [[User Status|page]] for new users and their current status. Thank you.

GT.M

2010-06-10T21:31:48Z

Butch: Removed external link and "better known as"

GT.M is an implementation of ANSII standardsMUMPS from Fidelity Information Systems. It is widely used in the banking world, and in addition, it will run VA VistA. At present the only well known alternative is [[Cache]]

Fidelity is the maintainer of [http://fisglobal.com/Products/TechnologyPlatforms/GTM/index.htm GT.M]. In addition to their open source version, they provide nonfree software that runs on the Oracle Solaris Operating System, running on the [http://en.wikipedia.org/wiki/SPARC Sun SPARC] line of high performance servers. They also offer service contracts and training to open source users.

Extensive documentation from Fidelity is [http://www.fisglobal.com/Products/TechnologyPlatforms/GTM/UserDocumentation/index.htm here]. See also [[GT.M Programmer's Guide]].

GT.M can support VistA. The portability layer of the Kernel is known to work with GT.M on VMS, Solaris, and Linux Operating System.

[[Category:MUMPS Implementation]]

GT.M

2010-06-10T21:30:29Z

Butch: added comment on Sun SPARC

GT.M is an implementation of ANSII standardsMUMPS from [http://www.fisglobal.com FIS], better known as Fidelity Information Systems. It is widely used in the banking world, and in addition, it will run VA VistA. At present the only well known alternative is [[Cache]]

Fidelity is the maintainer of [http://fisglobal.com/Products/TechnologyPlatforms/GTM/index.htm GT.M]. In addition to their open source version, they provide nonfree software that runs on the Oracle Solaris Operating System, running on the [http://en.wikipedia.org/wiki/SPARC Sun SPARC] line of high performance servers. They also offer service contracts and training to open source users.

Extensive documentation from Fidelity is [http://www.fisglobal.com/Products/TechnologyPlatforms/GTM/UserDocumentation/index.htm here]. See also [[GT.M Programmer's Guide]].

GT.M can support VistA. The portability layer of the Kernel is known to work with GT.M on VMS, Solaris, and Linux Operating System.

[[Category:MUMPS Implementation]]

GT.M

2010-06-10T21:29:19Z

Butch: Added Oracle Solaris

GT.M is an implementation of ANSII standardsMUMPS from [http://www.fisglobal.com FIS], better known as Fidelity Information Systems. It is widely used in the banking world, and in addition, it will run VA VistA. At present the only well known alternative is [[Cache]]

Fidelity is the maintainer of [http://fisglobal.com/Products/TechnologyPlatforms/GTM/index.htm GT.M]. In addition to their open source version, they provide nonfree software that runs on the Oracle Solaris Operating System, running on the [http://en.wikipedia.org/wiki/SPARC Sun SPARC] line of high performance servers. They also offer service contracts and training to open source users.

Extensive documentation from Fidelity is [http://www.fisglobal.com/Products/TechnologyPlatforms/GTM/UserDocumentation/index.htm here]. See also [[GT.M Programmer's Guide]].

GT.M can support VistA. The portability layer of the Kernel is known to work with GT.M on VMS, Solaris, and Linux Operating System.

[[Category:MUMPS Implementation]]

GT.M

2010-06-10T21:18:09Z

Butch: Contextual edits

GT.M is an implementation of ANSII standardsMUMPS from [http://www.fisglobal.com FIS], better known as Fidelity Information Systems. It is widely used in the banking world, and in addition, it will run VA VistA. At present the only well known alternative is [[Cache]]

Fidelity is the maintainer of [http://fisglobal.com/Products/TechnologyPlatforms/GTM/index.htm GT.M]. In addition to their open source version, they provide nonfree software that runs on the [http://en.wikipedia.org/wiki/SPARC Sun SPARC] line of high performance servers. They also offer service contracts and training to open source users.

Extensive documentation from Fidelity is [http://www.fisglobal.com/Products/TechnologyPlatforms/GTM/UserDocumentation/index.htm here]. See also [[GT.M Programmer's Guide]].

GT.M can support VistA. The portability layer of the Kernel is known to work with GT.M on VMS, Solaris, and Linux Operating System.

[[Category:MUMPS Implementation]]

User:Butch

2010-06-10T21:12:18Z

Butch:

I'm the senior sys admin for Elementary Dr Watson, a small (and growing) organization devoted to providing VistA to the small family practice market. I have several years experience working with UNIX and it's derivatives, from the user perspective, the admin perspective, and to a much smaller degree a developer. (A degree which is expanding daily).

OpenSolaris

2010-06-02T17:53:46Z

Butch: Removed signature line

OpenSolaris: What is it exactly?

OpenSolaris also commonly referred to as osol, is a completely free and open source version of the Sun Microsystems Solaris operating system, licensed under the CDDL. It is also the code base for the up and coming Solaris 11.

It is most commonly distributed as a live CD, that can be installed to your hard disk, in the same way that many modern Linux distros can. It makes use of the Gnome desktop, although others are available. If you want to take it for a spin, and get a feel for what it's all about you can download it here. 
http://www.opensolaris.org 
Click on the Get It! Link, and you will be directed to the download page.

OpenSolaris: A platform for VistA?

Utilizing a virtualization technology called zones (or containers which is slightly different), the Linux version of GT.M (and thus VistA) run un-modified. You still have a great deal of the functionality that exists in Linux, in addition to technologies only found in Solaris operating systems. A couple of the most popular and significant being [http://en.wikipedia.org/wiki/Zfs ZFS], and [http://opensolaris.org/os/project/crossbow Crossbow].

OpenSolaris zones

2010-03-15T20:17:20Z

Butch: /* Download the template file */ Updated link to template file

==Why I wrote this document, and why you should consider OpenSolaris==

Q. Why did I write this? 
A. Several reasons; here are a few of them:
* First and foremost, choice: OpenSolaris is a tool you may want to use to tackle whatever endeavor you are contemplating. In the context of this article, you might consider using it as a platform for VistA.
* To inform: Relatively few people know that OpenSolaris even exists, and even fewer know anything about using it. This is something it shares with VistA. They are both extremely powerful software environments, and are so expansive that it would be nearly impossible for any one person to know everything. That very expansiveness fosters a community of users, from all parts of the world.
* To share: I have been using OpenSolaris for over a year now, and previously used Solaris 10 since 2007. I have gained a lot of experience with the OS, and think that I may be able to provide help and insight as to different ways to attack a given problem.

Q. Why should you consider OpenSolaris? 
A. I think a better question might be, why '''''shouldn't''''' you try OpenSolaris. If you're reading this then you must be at least slightly interested, so here are a few reasons why you should try it.

* [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris] was designed from the beginning for enterprise computing.
* [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] "The last word in filesystems!"
* [http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit Dtrace] Wanna know what your program is doing? Dtrace allows developers and system admins, ways to look at running programs in ways that weren't possible before.
* [http://hub.opensolaris.org/bin/view/Community+Group+xen/WebHome xVM] The OpenSolaris version of the popular Xen hypervisor.
* [http://hub.opensolaris.org/bin/view/Community+Group+zones/WebHome Zones/Containers]. OS level virtualization, zones allow for completely isolated instances for running software. This is similar to the xVM hypervisor in that it allows absolute containment of applications and utilities, the biggest difference being, xVM requires a separate kernel, and running operating system. Zones utilize a single operating system instance, and don't incur the overhead associated with a hypervisor based model. However, xVM and Zones are ''NOT'' mutually exclusive, and work quite well in parallel. Zones are the main focus of this document.
* [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow]: The new virtualized networking stack built into the current release of OpenSolaris
* Support: You can get help from the [http://opensolaris.org/jive/index.jspa forums], [http://www.sun.com/service/opensolaris/ support contracts] from Sun, and as with most any other question, [http://www.google.com Google] is an invaluable resource.
* [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome BrandZ]: An extension of the zone/container framework, designed to support Linux applications on the OpenSolaris platform. People have run apps ranging from Apache for Linux, to Unreal Tournament 2004 (playable with audio), to modern day game servers, to GT.M. There is a pretty high likelihood that if you can do it in Linux, you can do it in a zone/container.

==What this document is==

This is a brief how to on settting up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. (That's a lower case "L" and is a reference to LinuX kernel 2.6). The goal here is to facilitate a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

==What this document is not==

This document is not meant as the be-all-end-all of zone documentation. There is a great deal more to the technology than I'm even going to begin to cover in this write up. If you want to know more about lx26 zones, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

These instructions are not meant for Amazon's EC2. The architecture of EC2 requires several additional steps, however the details of such are well beyond the scope or intent of this document.

==What are zones?==
* A virtualized operating system environment
* Each zone has its own characteristics e.g. zonename, IP addresses, hostname, naming services, root and non-root users
* Isolated application environments within a single OS instance

==Document Conventions==

When I use the term “virtual machine”, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to VirtualBox, or the Xen and vmWare hypervisors. In the latter 3 cases I will refer to them by name.

==What's needed==

Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover these 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being that a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==

Setting and configurations based on how I did this: (Adjust to your specific situation)
# You have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.
# You know how to add users and set permissions on a directory.
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is used in this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...substitute whatever name you feel appropriate, where it's appropriate.

==Setting up the virtualization environment==

To enable lx26 zone support

===Download the template file===

<pre>
user@computer# cd /etc/zones
user@computer# wget http://hub.opensolaris.org/bin/download/Community+Group+zones/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>

===Create the zone===

This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>

===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>

====Booting and logging in to the zone====

At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
At this point you need logout and back into the virtual machine, either by SSH or by zlogin without the -S flag.
<pre>
user@computer# zlogin zone1
</pre>
The logout/in process is necessary to do as logging in with zlogin -S gives you the equivalent of a single user Linux environment, and many of the tools and such wont work.

Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
user@computer# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. Current testing shows no negative impact on [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm] based VistA installations.

Now your zone is ready to take for a spin. Even though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want. There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums [http://opensolaris.org/jive/index.jspa here]. The next section has some very brief information about installing VistA inside of the completed zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admin's point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

-- 
[[User:Butch | Butch]]

OpenSolaris zones

2010-02-02T21:55:33Z

Butch: /* Download the template file */

==Why I wrote this document, and why you should consider OpenSolaris==

Q. Why did I write this? 
A. Several reasons; here are a few of them:
* First and foremost, choice: OpenSolaris is a tool you may want to use to tackle whatever endeavor you are contemplating. In the context of this article, you might consider using it as a platform for VistA.
* To inform: Relatively few people know that OpenSolaris even exists, and even fewer know anything about using it. This is something it shares with VistA. They are both extremely powerful software environments, and are so expansive that it would be nearly impossible for any one person to know everything. That very expansiveness fosters a community of users, from all parts of the world.
* To share: I have been using OpenSolaris for over a year now, and previously used Solaris 10 since 2007. I have gained a lot of experience with the OS, and think that I may be able to provide help and insight as to different ways to attack a given problem.

Q. Why should you consider OpenSolaris? 
A. I think a better question might be, why '''''shouldn't''''' you try OpenSolaris. If you're reading this then you must be at least slightly interested, so here are a few reasons why you should try it.

* [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris] was designed from the beginning for enterprise computing.
* [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] "The last word in filesystems!"
* [http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit Dtrace] Wanna know what your program is doing? Dtrace allows developers and system admins, ways to look at running programs in ways that weren't possible before.
* [http://hub.opensolaris.org/bin/view/Community+Group+xen/WebHome xVM] The OpenSolaris version of the popular Xen hypervisor.
* [http://hub.opensolaris.org/bin/view/Community+Group+zones/WebHome Zones/Containers]. OS level virtualization, zones allow for completely isolated instances for running software. This is similar to the xVM hypervisor in that it allows absolute containment of applications and utilities, the biggest difference being, xVM requires a separate kernel, and running operating system. Zones utilize a single operating system instance, and don't incur the overhead associated with a hypervisor based model. However, xVM and Zones are ''NOT'' mutually exclusive, and work quite well in parallel. Zones are the main focus of this document.
* [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow]: The new virtualized networking stack built into the current release of OpenSolaris
* Support: You can get help from the [http://opensolaris.org/jive/index.jspa forums], [http://www.sun.com/service/opensolaris/ support contracts] from Sun, and as with most any other question, [http://www.google.com Google] is an invaluable resource.
* [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome BrandZ]: An extension of the zone/container framework, designed to support Linux applications on the OpenSolaris platform. People have run apps ranging from Apache for Linux, to Unreal Tournament 2004 (playable with audio), to modern day game servers, to GT.M. There is a pretty high likelihood that if you can do it in Linux, you can do it in a zone/container.

==What this document is==

This is a brief how to on settting up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. (That's a lower case "L" and is a reference to LinuX kernel 2.6). The goal here is to facilitate a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

==What this document is not==

This document is not meant as the be-all-end-all of zone documentation. There is a great deal more to the technology than I'm even going to begin to cover in this write up. If you want to know more about lx26 zones, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

These instructions are not meant for Amazon's EC2. The architecture of EC2 requires several additional steps, however the details of such are well beyond the scope or intent of this document.

==What are zones?==
* A virtualized operating system environment
* Each zone has its own characteristics e.g. zonename, IP addresses, hostname, naming services, root and non-root users
* Isolated application environments within a single OS instance

==Document Conventions==

When I use the term “virtual machine”, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to VirtualBox, or the Xen and vmWare hypervisors. In the latter 3 cases I will refer to them by name.

==What's needed==

Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover these 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being that a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==

Setting and configurations based on how I did this: (Adjust to your specific situation)
# You have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.
# You know how to add users and set permissions on a directory.
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is used in this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...substitute whatever name you feel appropriate, where it's appropriate.

==Setting up the virtualization environment==

To enable lx26 zone support

===Download the template file===

<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/zones/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>

===Create the zone===

This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>

===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>

====Booting and logging in to the zone====

At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
At this point you need logout and back into the virtual machine, either by SSH or by zlogin without the -S flag.
<pre>
user@computer# zlogin zone1
</pre>
The logout/in process is necessary to do as logging in with zlogin -S gives you the equivalent of a single user Linux environment, and many of the tools and such wont work.

Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
user@computer# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. Current testing shows no negative impact on [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm] based VistA installations.

Now your zone is ready to take for a spin. Even though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want. There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums [http://opensolaris.org/jive/index.jspa here]. The next section has some very brief information about installing VistA inside of the completed zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admin's point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

-- 
[[User:Butch | Butch]]

User:Butch

2010-02-02T18:58:32Z

Butch:

Talk:OpenSolaris zones

2010-02-02T15:56:26Z

Butch: response:

Butch -- you should clean up this page.

It's quite rambling and repetitive.

Whittle, Whitby, whittle!

Quoting your response to Dr Watson:

"Don't use "I" or "you," especially "you should." It is pedantic and preachy and is a sin that exists uniquely in American speech patterns. Be cognizant that your method works for you and is primarily a suggestion; someone else may have found a better method. Conversely, don't be self-deprecating ("this works for me"). Just put down the advice without qualifiers and let other contributors edit it as necessary. Wikis are not like the US Congress (where posturing trumps results and very little of substance gets done).
"

Thank you for your input. Constructive criticism is always welcome. Perhaps if you feel it's "rambling and repetitive" then you should contribute to the document and edit the page as you see fit? This is a wiki after all, and changes are welcome. I'm not gonna pack up my toys and go home if you edit my work.

After having this article positively reviewed by 2 engineers at Sun Microsystems, 1 engineer from Oracle, and members of the OpenSolaris community I see little need to change it. Further after putting this document in the hands of several computer novices who have followed it without me having to hold their hand, I see even less need to change it.

However from this point forward, lest we begin to look like we are trolling each other we should move all further interactions to personal email. Vistapedia, is a place for factual writings, not personal opinions or debates. We have the forums for that. We should do our part to maintain that standard. Being that you are the first person within the community to directly address this writing I look forward to talking with you further in the future.

--
[[User:Butch | Butch]]

OpenSolaris zones

2010-02-02T14:33:23Z

Butch:

==Why I wrote this document, and why you should consider OpenSolaris==

Q. Why did I write this? 
A. Several reasons; here are a few of them:
* First and foremost, choice: OpenSolaris is a tool you may want to use to tackle whatever endeavor you are contemplating. In the context of this article, you might consider using it as a platform for VistA.
* To inform: Relatively few people know that OpenSolaris even exists, and even fewer know anything about using it. This is something it shares with VistA. They are both extremely powerful software environments, and are so expansive that it would be nearly impossible for any one person to know everything. That very expansiveness fosters a community of users, from all parts of the world.
* To share: I have been using OpenSolaris for over a year now, and previously used Solaris 10 since 2007. I have gained a lot of experience with the OS, and think that I may be able to provide help and insight as to different ways to attack a given problem.

Q. Why should you consider OpenSolaris? 
A. I think a better question might be, why '''''shouldn't''''' you try OpenSolaris. If you're reading this then you must be at least slightly interested, so here are a few reasons why you should try it.

* [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris] was designed from the beginning for enterprise computing.
* [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] "The last word in filesystems!"
* [http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit Dtrace] Wanna know what your program is doing? Dtrace allows developers and system admins, ways to look at running programs in ways that weren't possible before.
* [http://hub.opensolaris.org/bin/view/Community+Group+xen/WebHome xVM] The OpenSolaris version of the popular Xen hypervisor.
* [http://hub.opensolaris.org/bin/view/Community+Group+zones/WebHome Zones/Containers]. OS level virtualization, zones allow for completely isolated instances for running software. This is similar to the xVM hypervisor in that it allows absolute containment of applications and utilities, the biggest difference being, xVM requires a separate kernel, and running operating system. Zones utilize a single operating system instance, and don't incur the overhead associated with a hypervisor based model. However, xVM and Zones are ''NOT'' mutually exclusive, and work quite well in parallel. Zones are the main focus of this document.
* [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow]: The new virtualized networking stack built into the current release of OpenSolaris
* Support: You can get help from the [http://opensolaris.org/jive/index.jspa forums], [http://www.sun.com/service/opensolaris/ support contracts] from Sun, and as with most any other question, [http://www.google.com Google] is an invaluable resource.
* [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome BrandZ]: An extension of the zone/container framework, designed to support Linux applications on the OpenSolaris platform. People have run apps ranging from Apache for Linux, to Unreal Tournament 2004 (playable with audio), to modern day game servers, to GT.M. There is a pretty high likelihood that if you can do it in Linux, you can do it in a zone/container.

==What this document is==

This is a brief how to on settting up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. (That's a lower case "L" and is a reference to LinuX kernel 2.6). The goal here is to facilitate a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

==What this document is not==

This document is not meant as the be-all-end-all of zone documentation. There is a great deal more to the technology than I'm even going to begin to cover in this write up. If you want to know more about lx26 zones, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

These instructions are not meant for Amazon's EC2. The architecture of EC2 requires several additional steps, however the details of such are well beyond the scope or intent of this document.

==What are zones?==
* A virtualized operating system environment
* Each zone has its own characteristics e.g. zonename, IP addresses, hostname, naming services, root and non-root users
* Isolated application environments within a single OS instance

==Document Conventions==

When I use the term “virtual machine”, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to VirtualBox, or the Xen and vmWare hypervisors. In the latter 3 cases I will refer to them by name.

==What's needed==

Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover these 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being that a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==

Setting and configurations based on how I did this: (Adjust to your specific situation)
# You have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.
# You know how to add users and set permissions on a directory.
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is used in this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...substitute whatever name you feel appropriate, where it's appropriate.

==Setting up the virtualization environment==

To enable lx26 zone support

===Download the template file===

<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>

===Create the zone===

This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>

===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>

====Booting and logging in to the zone====

At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
At this point you need logout and back into the virtual machine, either by SSH or by zlogin without the -S flag.
<pre>
user@computer# zlogin zone1
</pre>
The logout/in process is necessary to do as logging in with zlogin -S gives you the equivalent of a single user Linux environment, and many of the tools and such wont work.

Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
user@computer# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. Current testing shows no negative impact on [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm] based VistA installations.

Now your zone is ready to take for a spin. Even though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want. There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums [http://opensolaris.org/jive/index.jspa here]. The next section has some very brief information about installing VistA inside of the completed zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admin's point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

-- 
[[User:Butch | Butch]]

OpenSolaris zones

2009-11-18T18:07:51Z

Butch: /* The Medsphere installation method */

==Why I wrote this document, and why you should consider OpenSolaris==

Q. Why did I write this? 
A. Several reasons, here are a few of them.
* First and foremost, choice: OpenSolaris is a tool to be used in whatever endeavor you may want to tackle with it. In the context of this article, using it as a platform for VistA.
* To inform: Relatively few people know anything about OpenSolaris and even fewer even know that it exists. This is something I think that it shares with VistA. They are both extremely powerful software environments, and are so expansive that it would be nearly impossible for any one person to know everything. That very expansiveness fosters a community of users, from all parts of the world.
* To share: I have been using OpenSolaris for over a year now, and previously used Solaris 10 since 2007. I have gained a lot of experience with the OS, and think that I may be able to provide help and insight as to different ways to attack a given problem.

Q. Why should you consider OpenSolaris? 
A. I think a better question might be, why '''''shouldn't''''' you try OpenSolaris. If your reading this than you must be at least slightly interested, so here are a few reasons why you should try it.

* [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris] was designed from the beginning for enterprise computing.
* [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] "The last word in filesystems!"
* [http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit Dtrace] Wanna know what your program is doing? Dtrace allows developers and system admins, ways to look at running programs in ways that weren't possible before.
* [http://hub.opensolaris.org/bin/view/Community+Group+xen/WebHome xVM] The OpenSolaris version of the popular Xen hypervisor.
* [http://hub.opensolaris.org/bin/view/Community+Group+zones/WebHome Zones/Containers]. OS level virtualization, zones allow for completely isolated instances for running software. This is similar to the xVM hypervisor in that it allows absolute containment of applications and utilities, the biggest difference being, xVM requires a separate kernel, and running operating system. Zones utilize a single operating system instance, and don't incur the overhead associated with a hypervisor based model. However, xVM and Zones are ''NOT'' mutually exclusive, and work quite well in parallel. Zones are the main focus of this document.
* [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow]: The new virtualized networking stack built into the current released of OpenSolaris
* Support: You can get help from the [http://opensolaris.org/jive/index.jspa forums], [http://www.sun.com/service/opensolaris/ support contracts] from Sun, and as with most any other question, [http://www.google.com Google] is an invaluable resource.
* [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome BrandZ]: An extension of the zone/container framework. Designed to support Linux applications on the OpenSolaris platform. People have run apps, ranging from Apache for Linux, to Unreal Tournament 2004 (playable with audio), to modern day game servers, to GT.M. There is a pretty high likelihood that if you can do it in Linux, you can do it in a zone/container.

==What this document is==

This is a brief how to on settting up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. (That's a lower case "L" and is a reference to LinuX kernel 2.6). The goal here is to facilitate a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

==What this document is not==

This document is not meant to be the be-all-end-all of zone documentation. There is a great deal more to the technology than I'm even going to begin to cover in this write up. If you want to know more about lx26 zones, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

These instructions are not meant for Amazon's EC2. The architecture of EC2 requires several additional steps, however the details of such are well beyond the scope or intent of this document.

==What are zones?==
* A virtualized operating system environment
* Each zone has its own characteristics e.g. zonename, IP addresses, hostname, naming services, root and non-root users
* Isolated application environments within a single OS instance

==Document Conventions==

When I use the term “virtual machine”, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to VirtualBox, or the Xen and vmWare hypervisors. In the latter 3 cases I will refer to them by name.

==What's needed==

Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==

Setting and configurations based on how I did this: (Adjust to your specific situation)
# You have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.
# You know how to add users and set permissions on a directory.
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is used in this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...substitute whatever name you feel appropriate, where it's appropriate.

==Setting up the virtualization environment==

To enable lx26 zone support

===Download the template file===

<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>

===Create the zone===

This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>

===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>

====Booting and logging in to the zone====

At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
At this point you need logout and back into the virtual machine, either by SSH or by zlogin without the -S flag.
<pre>
user@computer# zlogin zone1
</pre>
The logout/in process is necessary to do as logging in with zlogin -S gives you the equivalent of a single user Linux environment, and many of the tools and such wont work.

Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
user@computer# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. Current testing shows no negative impact on [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm] based VistA installations.

Now your zone is ready to take for a spin. Even though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want. There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums [http://opensolaris.org/jive/index.jspa here]. The next section has some very brief information about installing VistA inside of the completed zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

-- 
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-11-18T18:07:13Z

Butch: /* Finishing up */ Context edit

OpenSolaris zones

2009-11-18T18:06:03Z

Butch: /* Finishing up */ Edited for informational accuracy

==Why I wrote this document, and why you should consider OpenSolaris==

Q. Why did I write this? 
A. Several reasons, here are a few of them.
* First and foremost, choice: OpenSolaris is a tool to be used in whatever endeavor you may want to tackle with it. In the context of this article, using it as a platform for VistA.
* To inform: Relatively few people know anything about OpenSolaris and even fewer even know that it exists. This is something I think that it shares with VistA. They are both extremely powerful software environments, and are so expansive that it would be nearly impossible for any one person to know everything. That very expansiveness fosters a community of users, from all parts of the world.
* To share: I have been using OpenSolaris for over a year now, and previously used Solaris 10 since 2007. I have gained a lot of experience with the OS, and think that I may be able to provide help and insight as to different ways to attack a given problem.

Q. Why should you consider OpenSolaris? 
A. I think a better question might be, why '''''shouldn't''''' you try OpenSolaris. If your reading this than you must be at least slightly interested, so here are a few reasons why you should try it.

* [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris] was designed from the beginning for enterprise computing.
* [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] "The last word in filesystems!"
* [http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit Dtrace] Wanna know what your program is doing? Dtrace allows developers and system admins, ways to look at running programs in ways that weren't possible before.
* [http://hub.opensolaris.org/bin/view/Community+Group+xen/WebHome xVM] The OpenSolaris version of the popular Xen hypervisor.
* [http://hub.opensolaris.org/bin/view/Community+Group+zones/WebHome Zones/Containers]. OS level virtualization, zones allow for completely isolated instances for running software. This is similar to the xVM hypervisor in that it allows absolute containment of applications and utilities, the biggest difference being, xVM requires a separate kernel, and running operating system. Zones utilize a single operating system instance, and don't incur the overhead associated with a hypervisor based model. However, xVM and Zones are ''NOT'' mutually exclusive, and work quite well in parallel. Zones are the main focus of this document.
* [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow]: The new virtualized networking stack built into the current released of OpenSolaris
* Support: You can get help from the [http://opensolaris.org/jive/index.jspa forums], [http://www.sun.com/service/opensolaris/ support contracts] from Sun, and as with most any other question, [http://www.google.com Google] is an invaluable resource.
* [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome BrandZ]: An extension of the zone/container framework. Designed to support Linux applications on the OpenSolaris platform. People have run apps, ranging from Apache for Linux, to Unreal Tournament 2004 (playable with audio), to modern day game servers, to GT.M. There is a pretty high likelihood that if you can do it in Linux, you can do it in a zone/container.

==What this document is==

This is a brief how to on settting up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. (That's a lower case "L" and is a reference to LinuX kernel 2.6). The goal here is to facilitate a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

==What this document is not==

This document is not meant to be the be-all-end-all of zone documentation. There is a great deal more to the technology than I'm even going to begin to cover in this write up. If you want to know more about lx26 zones, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

These instructions are not meant for Amazon's EC2. The architecture of EC2 requires several additional steps, however the details of such are well beyond the scope or intent of this document.

==What are zones?==
* A virtualized operating system environment
* Each zone has its own characteristics e.g. zonename, IP addresses, hostname, naming services, root and non-root users
* Isolated application environments within a single OS instance

==Document Conventions==

When I use the term “virtual machine”, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to VirtualBox, or the Xen and vmWare hypervisors. In the latter 3 cases I will refer to them by name.

==What's needed==

Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==

Setting and configurations based on how I did this: (Adjust to your specific situation)
# You have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.
# You know how to add users and set permissions on a directory.
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is used in this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...substitute whatever name you feel appropriate, where it's appropriate.

==Setting up the virtualization environment==

To enable lx26 zone support

===Download the template file===

<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>

===Create the zone===

This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>

===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>

====Booting and logging in to the zone====

At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
At this point you need logout and back into the virtual machine, either by SSH or by zlogin without the -S flag.
<pre>
user@computer# zlogin zone1
</pre>
It is necessary to do so as logging in with zlogin -S gives you the equivalent of a single user Linux environment, and many of the tools and such wont work.

Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
user@computer# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. Current testing shows no negative impact on [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm] based VistA installations.

Now your zone is ready to take for a spin. Even though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want. There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums [http://opensolaris.org/jive/index.jspa here]. The next section has some very brief information about installing VistA inside of the completed zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-10-30T15:55:34Z

Butch: /* What this document is not */ Edited EC2

==Why I wrote this document, and why you should consider OpenSolaris==

Q. Why did I write this? 
A. Several reasons, here are a few of them.
* First and foremost, choice: OpenSolaris is a tool to be used in whatever endeavor you may want to tackle with it. In the context of this article, using it as a platform for VistA.
* To inform: Relatively few people know anything about OpenSolaris and even fewer even know that it exists. This is something I think that it shares with VistA. They are both extremely powerful software environments, and are so expansive that it would be nearly impossible for any one person to know everything. That very expansiveness fosters a community of users, from all parts of the world.
* To share: I have been using OpenSolaris for over a year now, and previously used Solaris 10 since 2007. I have gained a lot of experience with the OS, and think that I may be able to provide help and insight as to different ways to attack a given problem.

Q. Why should you consider OpenSolaris? 
A. I think a better question might be, why '''''shouldn't''''' you try OpenSolaris. If your reading this than you must be at least slightly interested, so here are a few reasons why you should try it.

* [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris] was designed from the beginning for enterprise computing.
* [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] "The last word in filesystems!"
* [http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit Dtrace] Wanna know what your program is doing? Dtrace allows developers and system admins, ways to look at running programs in ways that weren't possible before.
* [http://hub.opensolaris.org/bin/view/Community+Group+xen/WebHome xVM] The OpenSolaris version of the popular Xen hypervisor.
* [http://hub.opensolaris.org/bin/view/Community+Group+zones/WebHome Zones/Containers]. OS level virtualization, zones allow for completely isolated instances for running software. This is similar to the xVM hypervisor in that it allows absolute containment of applications and utilities, the biggest difference being, xVM requires a separate kernel, and running operating system. Zones utilize a single operating system instance, and don't incur the overhead associated with a hypervisor based model. However, xVM and Zones are ''NOT'' mutually exclusive, and work quite well in parallel. Zones are the main focus of this document.
* [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow]: The new virtualized networking stack built into the current released of OpenSolaris
* Support: You can get help from the [http://opensolaris.org/jive/index.jspa forums], [http://www.sun.com/service/opensolaris/ support contracts] from Sun, and as with most any other question, [http://www.google.com Google] is an invaluable resource.
* [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome BrandZ]: An extension of the zone/container framework. Designed to support Linux applications on the OpenSolaris platform. People have run apps, ranging from Apache for Linux, to Unreal Tournament 2004 (playable with audio), to modern day game servers, to GT.M. There is a pretty high likelihood that if you can do it in Linux, you can do it in a zone/container.

==What this document is==

This is a brief how to on settting up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. (That's a lower case "L" and is a reference to LinuX kernel 2.6). The goal here is to facilitate a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

==What this document is not==

This document is not meant to be the be-all-end-all of zone documentation. There is a great deal more to the technology than I'm even going to begin to cover in this write up. If you want to know more about lx26 zones, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

These instructions are not meant for Amazon's EC2. The architecture of EC2 requires several additional steps, however the details of such are well beyond the scope or intent of this document.

==What are zones?==
* A virtualized operating system environment
* Each zone has its own characteristics e.g. zonename, IP addresses, hostname, naming services, root and non-root users
* Isolated application environments within a single OS instance

==Document Conventions==

When I use the term “virtual machine”, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to VirtualBox, or the Xen and vmWare hypervisors. In the latter 3 cases I will refer to them by name.

==What's needed==

Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==

Setting and configurations based on how I did this: (Adjust to your specific situation)
# You have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.
# You know how to add users and set permissions on a directory.
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is used in this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...substitute whatever name you feel appropriate, where it's appropriate.

==Setting up the virtualization environment==

To enable lx26 zone support

===Download the template file===

<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>

===Create the zone===

This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>

===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>

====Booting and logging in to the zone====

At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. Current testing shows no negative impact on [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm] based VistA installations.

Now your zone is ready to take for a spin. Even though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want. There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums [http://opensolaris.org/jive/index.jspa here]. The next section has some very brief information about installing VistA inside of the completed zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-10-30T15:52:57Z

Butch:

==Why I wrote this document, and why you should consider OpenSolaris==

Q. Why did I write this? 
A. Several reasons, here are a few of them.
* First and foremost, choice: OpenSolaris is a tool to be used in whatever endeavor you may want to tackle with it. In the context of this article, using it as a platform for VistA.
* To inform: Relatively few people know anything about OpenSolaris and even fewer even know that it exists. This is something I think that it shares with VistA. They are both extremely powerful software environments, and are so expansive that it would be nearly impossible for any one person to know everything. That very expansiveness fosters a community of users, from all parts of the world.
* To share: I have been using OpenSolaris for over a year now, and previously used Solaris 10 since 2007. I have gained a lot of experience with the OS, and think that I may be able to provide help and insight as to different ways to attack a given problem.

Q. Why should you consider OpenSolaris? 
A. I think a better question might be, why '''''shouldn't''''' you try OpenSolaris. If your reading this than you must be at least slightly interested, so here are a few reasons why you should try it.

* [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris] was designed from the beginning for enterprise computing.
* [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] "The last word in filesystems!"
* [http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit Dtrace] Wanna know what your program is doing? Dtrace allows developers and system admins, ways to look at running programs in ways that weren't possible before.
* [http://hub.opensolaris.org/bin/view/Community+Group+xen/WebHome xVM] The OpenSolaris version of the popular Xen hypervisor.
* [http://hub.opensolaris.org/bin/view/Community+Group+zones/WebHome Zones/Containers]. OS level virtualization, zones allow for completely isolated instances for running software. This is similar to the xVM hypervisor in that it allows absolute containment of applications and utilities, the biggest difference being, xVM requires a separate kernel, and running operating system. Zones utilize a single operating system instance, and don't incur the overhead associated with a hypervisor based model. However, xVM and Zones are ''NOT'' mutually exclusive, and work quite well in parallel. Zones are the main focus of this document.
* [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow]: The new virtualized networking stack built into the current released of OpenSolaris
* Support: You can get help from the [http://opensolaris.org/jive/index.jspa forums], [http://www.sun.com/service/opensolaris/ support contracts] from Sun, and as with most any other question, [http://www.google.com Google] is an invaluable resource.
* [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome BrandZ]: An extension of the zone/container framework. Designed to support Linux applications on the OpenSolaris platform. People have run apps, ranging from Apache for Linux, to Unreal Tournament 2004 (playable with audio), to modern day game servers, to GT.M. There is a pretty high likelihood that if you can do it in Linux, you can do it in a zone/container.

==What this document is==

This is a brief how to on settting up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. (That's a lower case "L" and is a reference to LinuX kernel 2.6). The goal here is to facilitate a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

==What this document is not==

This document is not meant to be the be-all-end-all of zone documentation. There is a great deal more to the technology than I'm even going to begin to cover in this write up. If you want to know more about lx26 zones, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

These instructions are not meant for Amazon's EC2 cloud architecture as written. It can be done however the details of such are well beyond the scope or intent of this document.

==What are zones?==
* A virtualized operating system environment
* Each zone has its own characteristics e.g. zonename, IP addresses, hostname, naming services, root and non-root users
* Isolated application environments within a single OS instance

==Document Conventions==

When I use the term “virtual machine”, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to VirtualBox, or the Xen and vmWare hypervisors. In the latter 3 cases I will refer to them by name.

==What's needed==

Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==

Setting and configurations based on how I did this: (Adjust to your specific situation)
# You have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.
# You know how to add users and set permissions on a directory.
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is used in this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...substitute whatever name you feel appropriate, where it's appropriate.

==Setting up the virtualization environment==

To enable lx26 zone support

===Download the template file===

<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>

===Create the zone===

This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>

===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>

====Booting and logging in to the zone====

At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. Current testing shows no negative impact on [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm] based VistA installations.

Now your zone is ready to take for a spin. Even though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want. There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums [http://opensolaris.org/jive/index.jspa here]. The next section has some very brief information about installing VistA inside of the completed zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-10-30T15:51:19Z

Butch: Edited doc structure

==Why I wrote this document, and why you should consider OpenSolaris==

Q. Why did I write this? 
A. Several reasons, here are a few of them.
* First and foremost, choice: OpenSolaris is a tool to be used in whatever endeavor you may want to tackle with it. In the context of this article, using it as a platform for VistA.
* To inform: Relatively few people know anything about OpenSolaris and even fewer even know that it exists. This is something I think that it shares with VistA. They are both extremely powerful software environments, and are so expansive that it would be nearly impossible for any one person to know everything. That very expansiveness fosters a community of users, from all parts of the world.
* To share: I have been using OpenSolaris for over a year now, and previously used Solaris 10 since 2007. I have gained a lot of experience with the OS, and think that I may be able to provide help and insight as to different ways to attack a given problem.

Q. Why should you consider OpenSolaris? 
A. I think a better question might be, why '''''shouldn't''''' you try OpenSolaris. If your reading this than you must be at least slightly interested, so here are a few reasons why you should try it.

* [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris] was designed from the beginning for enterprise computing.
* [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] "The last word in filesystems!"
* [http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit Dtrace] Wanna know what your program is doing? Add a couple of dtrace probes, and see things that have never been possible before.
* [http://hub.opensolaris.org/bin/view/Community+Group+xen/WebHome xVM] The OpenSolaris version of the popular Xen hypervisor.
* [http://hub.opensolaris.org/bin/view/Community+Group+zones/WebHome Zones/Containers]. OS level virtualization, zones allow for completely isolated instances for running software. This is similar to the xVM hypervisor in that it allows absolute containment of applications and utilities, the biggest difference being, xVM requires a separate kernel, and running operating system. Zones utilize a single operating system instance, and don't incur the overhead associated with a hypervisor based model. However, xVM and Zones are ''NOT'' mutually exclusive, and work quite well in parallel. Zones are the main focus of this document.
* [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow]: The new virtualized networking stack built into the current released of OpenSolaris
* Support: You can get help from the [http://opensolaris.org/jive/index.jspa forums], [http://www.sun.com/service/opensolaris/ support contracts] from Sun, and as with most any other question, [http://www.google.com Google] is an invaluable resource.
* [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome BrandZ]: An extension of the zone/container framework. Designed to support Linux applications on the OpenSolaris platform. People have run apps, ranging from Apache for Linux, to Unreal Tournament 2004 (playable with audio), to modern day game servers, to GT.M. There is a pretty high likelihood that if you can do it in Linux, you can do it in a zone/container.

==What this document is==

This is a brief how to on settting up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. (That's a lower case "L" and is a reference to LinuX kernel 2.6). The goal here is to facilitate a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

==What this document is not==

This document is not meant to be the be-all-end-all of zone documentation. There is a great deal more to the technology than I'm even going to begin to cover in this write up. If you want to know more about lx26 zones, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

These instructions are not meant for Amazon's EC2 cloud architecture as written. It can be done however the details of such are well beyond the scope or intent of this document.

==What are zones?==
* A virtualized operating system environment
* Each zone has its own characteristics e.g. zonename, IP addresses, hostname, naming services, root and non-root users
* Isolated application environments within a single OS instance

==Document Conventions==

When I use the term “virtual machine”, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to VirtualBox, or the Xen and vmWare hypervisors. In the latter 3 cases I will refer to them by name.

==What's needed==

Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==

Setting and configurations based on how I did this: (Adjust to your specific situation)
# You have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.
# You know how to add users and set permissions on a directory.
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is used in this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...substitute whatever name you feel appropriate, where it's appropriate.

==Setting up the virtualization environment==

To enable lx26 zone support

===Download the template file===

<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>

===Create the zone===

This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>

===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>

====Booting and logging in to the zone====

At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. Current testing shows no negative impact on [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm] based VistA installations.

Now your zone is ready to take for a spin. Even though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want. There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums [http://opensolaris.org/jive/index.jspa here]. The next section has some very brief information about installing VistA inside of the completed zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-10-30T15:18:07Z

Butch: Added what are zones

==What this document is==

This is a brief how to on settting up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. (That's a lower case "L" and is a reference to LinuX kernel 2.6). The goal here is to facilitate a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

==What this document is not==

This document is not meant to be the be-all-end-all of zone documentation. There is a great deal more to the technology than I'm even going to begin to cover in this write up. If you want to know more about lx26 zones, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

These instructions are not meant for Amazon's EC2 cloud architecture as written. It can be done however the details of such are well beyond the scope or intent of this document.

==What are zones?==
* A virtualized operating system environment
* Each zone has its own characteristics e.g. zonename, IP addresses, hostname, naming services, root and non-root users
* Isolated application environments within a single OS instance

==Document Conventions==

When I use the term “virtual machine”, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to VirtualBox, or the Xen and vmWare hypervisors. In the latter 3 cases I will refer to them by name.

==Why I wrote this document, and why you should consider OpenSolaris==

Q. Why did I write this? 
A. Several reasons, here are a few of them.
* First and foremost, choice: OpenSolaris is a tool to be used in whatever endeavor you may want to tackle with it. In the context of this article, using it as a platform for VistA.
* To inform: Relatively few people know anything about OpenSolaris and even fewer even know that it exists. This is something I think that it shares with VistA. They are both extremely powerful software environments, and are so expansive that it would be nearly impossible for any one person to know everything. That very expansiveness fosters a community of users, from all parts of the world.
* To share: I have been using OpenSolaris for over a year now, and previously used Solaris 10 since 2007. I have gained a lot of experience with the OS, and think that I may be able to provide help and insight as to different ways to attack a given problem.

Q. Why should you consider OpenSolaris? 
A. I think a better question might be, why '''''shouldn't''''' you try OpenSolaris. If your reading this than you must be at least slightly interested, so here are a few reasons why you should try it.

* [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris] was designed from the beginning for enterprise computing.
* [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] "The last word in filesystems!"
* [http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit Dtrace] Wanna know what your program is doing? Add a couple of dtrace probes, and see things that have never been possible before.
* [http://hub.opensolaris.org/bin/view/Community+Group+xen/WebHome xVM] The OpenSolaris version of the popular Xen hypervisor.
* [http://hub.opensolaris.org/bin/view/Community+Group+zones/WebHome Zones/Containers]. OS level virtualization, zones allow for completely isolated instances for running software. This is similar to the xVM hypervisor in that it allows absolute containment of applications and utilities, the biggest difference being, xVM requires a separate kernel, and running operating system. Zones utilize a single operating system instance, and don't incur the overhead associated with a hypervisor based model. However, xVM and Zones are ''NOT'' mutually exclusive, and work quite well in parallel. Zones are the main focus of this document.
* [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow]: The new virtualized networking stack built into the current released of OpenSolaris
* Support: You can get help from the [http://opensolaris.org/jive/index.jspa forums], [http://www.sun.com/service/opensolaris/ support contracts] from Sun, and as with most any other question, [http://www.google.com Google] is an invaluable resource.
* [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome BrandZ]: An extension of the zone/container framework. Designed to support Linux applications on the OpenSolaris platform. People have run apps, ranging from Apache for Linux, to Unreal Tournament 2004 (playable with audio), to modern day game servers, to GT.M. There is a pretty high likelihood that if you can do it in Linux, you can do it in a zone/container.

==What's needed==

Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==

Setting and configurations based on how I did this: (Adjust to your specific situation)
# You have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.
# You know how to add users and set permissions on a directory.
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is used in this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...substitute whatever name you feel appropriate, where it's appropriate.

==Setting up the virtualization environment==

To enable lx26 zone support

===Download the template file===

<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>

===Create the zone===

This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>

===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>

====Booting and logging in to the zone====

At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. Current testing shows no negative impact on [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm] based VistA installations.

Now your zone is ready to take for a spin. Even though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want. There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums [http://opensolaris.org/jive/index.jspa here]. The next section has some very brief information about installing VistA inside of the completed zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

Linux Active Directory How-To

2009-10-30T15:14:41Z

Butch: Edited markup, and content

Linux Active Directory How-To

==Document scope==

This document briefly describes how to configure a GNU/Linux machine to authenticate users against a
Microsoft Windows Server 2003 Active Directory Server.

The idea behind this is to use Windows 2003 ADS (and possibly later versions) to authenticate a foreign user and allow him/her to use a Linux machine which is a member of the Windows domain, without having to create a user account manually on the Linux machine. This is very useful when you have large numbers of machines and users.

If everything works as it should, then you only need to configure the users on the Active Directory Server. The users can then walk up to any machine on the network and log on. If a user never used that machine before, a user account will be magically created. The magic trick is known as Single Sign-On (SSO).

The whole process is rather complicated and relies on a number of subsystems working together:
* Pluggable Authentication Modules (PAM)
* Server Message Block (SMB, Samba)
* WinBIND (part of Samba)
* Kerberos 5 (By MIT, with Microsoft compatibility hacks)

The biggest problem is configuring Samba and determining exactly what identifiers and spelling to use where, since Kerberos and NETBIOS are fond of uppercase, while everything else prefers lowercase.

Of course, nothing works, until every last little detail is correct, so these and other subtleties can lead to many hours of happy debugging and experimenting before everything suddenly begins to work.
Just about every imaginable error message was discovered the hard way and they were all documented in the references below. Of course, since you will be following this great guide, you wont ever see them - let's hope anyway.

Note that everything here was tested on Linux, but it should also apply almost directly to Solaris, since Samba is cross platform.

==Referenced Documents==

* Chapter 6. Domain membership part II, Server configuration basics: HTTP://us4.samba.org/samba/docs/man/samba-howto-collection/domain-member.html#ads-member

* Chapter 24. Winbind: Use of Domain Accounts Part III. Advanced Configuration, HTTP://us4.samba.org/samba/docs/man/samba-howto-collection/winbind.html

* Kerberos Administration Guide, HTTP://web.mit.edu/kerberos/krb5-1.3/krb5-1.3/doc/krb5-admin.html

* Linux PAM, HTTP://www.kernel.org/pub/linux/libs/pam3.

==Configuration==

We want to use the Windows 2003 Active Directory Server (ADS) to authenticate a foreign user and allow him or her to use a Linux machine which is a member of the Windows domain. Initially, the user jdoe doesn't exist on the Linux machine. We want to use Winbind and Samba to assign a UID and GID from a pool of reserve numbers and create a home directory automatically under /home/winnt for this foreign user. This will (hopefully) allow jdoe to walk up to the Linux machine, log in and use it to run X applications, without ever having been manually configured on it.

This guide assumes that you already have a Windows ADS running. First verify a few things on the Windows ADS machine and note that the NETBIOS work group must be uppercase:
<pre>
NETBIOS Workgroup: YOURWORKGROUPNAME
Domain name: example.com
Fully qualified domain host name: msads.example.com
User name defined in ADS: jdoe
User password: jdoe123
User primary group: winusergrp
Administrator name: Administrator
Administrator password: Supersecret
</pre>
This illustrates some weird points. Rather confusingly, the MS Windows NETBIOS work group, is also referred to as the domain name in MS Windows documentation. The NETBIOS work group is actually used more often than the real domain name, so when in doubt, use the NETBIOS work group, since it will usually be the correct one for the occasion.

The MS Windows user name, will become work group+user name on Linux, and the Windows primary group, will become the work group+group name on Linux.

===Kerberos===

Kerberos is configured in the file /etc/krb5.conf. Verify the following lines and not the UPPERCASE domain name:

<pre>
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM =
{
kdc = msads.example.com>
}
[domain_realms]
.kerberos.server = EXAMPLE.COM
</pre>

Note that Kerberos requires that the clocks of the machines in the domain are synchronized in time. The default maximum skew allowed is 5 minutes. Windows and Linux handle times differently. UNIX is UTC based, and Windows is local time zone based, so be careful. Configuring NTP is necessary, but is also beyond the scope of this document.

===Nsswitch Configuration===

Verify the following lines in /etc/nsswitch.conf:
<pre>
passwd: files winbind
shadow: files winbind
group: files winbind
</pre>
You may need to run ldconfig to set up the winbind libraries:

user@comp# ldconfig -v |grep winbind

Since nothing was working at the time, I cannot tell whether that was really a required step.

===Samba configuration===

Here's the [global] section from smb.conf:

<pre>
[global]
workgroup = YOURWORKGROUPNAME
realm = EXAMPLE.COM
preferred master = no
server string = Samba Server
security = ADS
encrypt passwords = yes
log level = 3
log file = /var/log/samba/%m
max log size = 50
winbind separator = +
printcap name = cups
printing = cups
idmap uid = 10000-20000
idmap gid = 10000-20000
template homedir /home/winnt/%D/%U
template shell = /bin/false
add machine script = /usr/sbin/useradd -d /var/lib/nobody -g 100 -s /bin/false -M %u
password server = msads.example.com
</pre>
The /bin/false shell will prevent foreign domain users from opening a command shell and is recommended for security.

The default Windind separator is a backslash, but that doesn't work well, since it is a reserve character on UNIX/Linux. The general rule is to change it to a '+'.

===Ethernet configuration===

You have to set the ADS machine as (one of) the DNS in /etc/resolv.conf, to enable the Linux machine to find the Kerberos and LDAP servers on the ADS. Verify the ethernet and DNS setting with ifconfig and nslookup.

===Join the Domain===

First restart the network and Samba:

user@comp # service network restart 
user@comp # service smb restart 

Verify that smbd and nmbd are running with

user@comp # ps e

Try to join the Windows Domain:

user@comp # net ads join -S msads.example.com -U administrator%Supersecret

You should get the message: "Joined LINUXMACHINE to realm EXAMPLE.COM", at which point most joyful celebrations are in order.

You can now start the Winbind daemon with the maximum debug information:

user@comp # winbindd -d 10

Watch /var/log/messages for errors:

user@comp # tail -f /var/log/messages

You can investigate the domain records with:

user@comp # wbinfo -u 
user@comp # whinfo -g 
user@comp # getent password 
user@comp # getent group 

With those utilities, you should be able to see the user names and groups in the domain that you just joined. User YOURWORKGROUPNAME+jdoe and the group
YOURWORKGROUPNAME+winusergrp should be listed.

===Kerberos and error messages===

If you get the message: Cannot find KDC for requested realm, then either the password server in smb.conf is wrong, or the DNS setting in resolv.conf is wrong.

If you get the message: KRB5 error code 68 while getting the initial credentials, then the Linux machine can talk to the ADS machine, but your Kerberos realm name in smb.conf is wrong.

If you get the message: The workgroup in smb.conf does not match the short domain name obtained from the server, then you did not specify the NETBIOS name properly.

-- 
[[User:Butch| Butch Whitby]]

OpenSolaris zones

2009-10-29T20:39:42Z

Butch: Content reconstructed, added multiple hyperlinks, edited content

==What this document is==

This is a brief how to on settting up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. (That's a lower case "L" and is a reference to LinuX kernel 2.6). The goal here is to facilitate a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

==What this document is not==

This document is not meant to be the be-all-end-all of zone documentation. There is a great deal more to the technology than I'm even going to begin to cover in this write up. If you want to know more about lx26 zones, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

These instructions are not meant for Amazon's EC2 cloud architecture as written. It can be done however the details of such are well beyond the scope or intent of this document.

==Document Conventions==

When I use the term “virtual machine”, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to VirtualBox, or the Xen and vmWare hypervisors. In the latter 3 cases I will refer to them by name.

==Why I wrote this document, and why you should consider OpenSolaris==

Q. Why did I write this? 
A. Several reasons, here are a few of them.
* First and foremost, choice: OpenSolaris is a tool to be used in whatever endeavor you may want to tackle with it. In the context of this article, using it as a platform for VistA.
* To inform: Relatively few people know anything about OpenSolaris and even fewer even know that it exists. This is something I think that it shares with VistA. They are both extremely powerful software environments, and are so expansive that it would be nearly impossible for any one person to know everything. That very expansiveness fosters a community of users, from all parts of the world.
* To share: I have been using OpenSolaris for over a year now, and previously used Solaris 10 since 2007. I have gained a lot of experience with the OS, and think that I may be able to provide help and insight as to different ways to attack a given problem.

Q. Why should you consider OpenSolaris? 
A. I think a better question might be, why '''''shouldn't''''' you try OpenSolaris. If your reading this than you must be at least slightly interested, so here are a few reasons why you should try it.

* [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris] was designed from the beginning for enterprise computing.
* [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] "The last word in filesystems!"
* [http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit Dtrace] Wanna know what your program is doing? Add a couple of dtrace probes, and see things that have never been possible before.
* [http://hub.opensolaris.org/bin/view/Community+Group+xen/WebHome xVM] The OpenSolaris version of the popular Xen hypervisor.
* [http://hub.opensolaris.org/bin/view/Community+Group+zones/WebHome Zones/Containers]. OS level virtualization, zones allow for completely isolated instances for running software. This is similar to the xVM hypervisor in that it allows absolute containment of applications and utilities, the biggest difference being, xVM requires a separate kernel, and running operating system. Zones utilize a single operating system instance, and don't incur the overhead associated with a hypervisor based model. However, xVM and Zones are ''NOT'' mutually exclusive, and work quite well in parallel. Zones are the main focus of this document.
* [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow]: The new virtualized networking stack built into the current released of OpenSolaris
* Support: You can get help from the [http://opensolaris.org/jive/index.jspa forums], [http://www.sun.com/service/opensolaris/ support contracts] from Sun, and as with most any other question, [http://www.google.com Google] is an invaluable resource.
* [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome BrandZ]: An extension of the zone/container framework. Designed to support Linux applications on the OpenSolaris platform. People have run apps, ranging from Apache for Linux, to Unreal Tournament 2004 (playable with audio), to modern day game servers, to GT.M. There is a pretty high likelihood that if you can do it in Linux, you can do it in a zone/container.

==What's needed==

Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==

Setting and configurations based on how I did this: (Adjust to your specific situation)
# You have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.
# You know how to add users and set permissions on a directory.
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is used in this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...substitute whatever name you feel appropriate, where it's appropriate.

==Setting up the virtualization environment==

To enable lx26 zone support

===Download the template file===

<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>

===Create the zone===

This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>

===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>

====Booting and logging in to the zone====

At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. Current testing shows no negative impact on [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm] based VistA installations.

Now your zone is ready to take for a spin. Even though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want. There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums [http://opensolaris.org/jive/index.jspa here]. The next section has some very brief information about installing VistA inside of the completed zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-10-29T20:18:36Z

Butch: /* What this document is not */ Edited for content

==Document Scope==

This document describes how to set up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. That's a lower case "L" and is a reference to LinuX kernel 2.6 The goal is facilitating a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazon's EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document. If you would like information regarding the advanced virtualized networking features of OpenSolaris, check out the [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow project].

==Why I wrote this document, and why you should consider OpenSolaris==

Q. Why did I write this? 
A. Several reasons, here are a few of them.
* First and foremost, choice: OpenSolaris is a tool to be used in whatever endeavor you may want to tackle with it. In the context of this article, using it as a platform for VistA.
* To inform: Relatively few people know anything about OpenSolaris and even fewer even know that it exists. This is something I think that it shares with VistA. They are both extremely powerful software environments, and are so expansive that it would be nearly impossible for any one person to know everything. That very expansiveness fosters a community of users, from all parts of the world.
* To share: I have been using OpenSolaris for over a year now, and previously used Solaris 10 since 2007. I have gained a lot of experience with the OS, and think that I may be able to provide help and insight as to different ways to attack a given problem.

Q. Why should you consider OpenSolaris? 
A. I think a better question might be, why '''''shouldn't''''' you try OpenSolaris. If your reading this than you must be at least slightly interested, so here are a few reasons why you should try it.

* [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris] was designed from the beginning for enterprise computing.
* [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] "The last word in filesystems!"
* [http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit Dtrace] Wanna know what your program is doing? Add a couple of dtrace probes, and see things that have never been possible before.
* [http://hub.opensolaris.org/bin/view/Community+Group+xen/WebHome xVM] The OpenSolaris version of the popular Xen hypervisor.
* [http://hub.opensolaris.org/bin/view/Community+Group+zones/WebHome Zones/Containers]. OS level virtualization, zones allow for completely isolated instances for running software. This is similar to the xVM hypervisor in that it allows absolute containment of applications and utilities, the biggest difference being, xVM requires a separate kernel, and running operating system. Zones utilize a single operating system instance, and don't incur the overhead associated with a hypervisor based model. However, xVM and Zones are ''NOT'' mutually exclusive, and work quite well in parallel. Zones are the main focus of this document.
* Support: You can get help from the [http://opensolaris.org/jive/index.jspa forums], [http://www.sun.com/service/opensolaris/ support contracts] from Sun, and as with most any other question, [http://www.google.com Google] is an invaluable resource.
* [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome BrandZ]: An extension of the zone/container framework. Designed to support Linux applications on the OpenSolaris platform. People have run apps, ranging from Apache for Linux, to Unreal Tournament 2004 (playable with audio), to modern day game servers, to GT.M. There is a pretty high likelihood that if you can do it in Linux, you can do it in a zone/container.

==What this document is not==
This document is not meant to be the be-all-end-all of zone documentation. There is a great deal more to the technology than I'm even going to begin to cover in this write up. If you want to know more about lx26 zones, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

==What's needed==
Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation)
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is set aside for this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...

==Setting up the virtualization environment==

To enable lx26 zone support
===Download the template file===
<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>
===Create the zone===
This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>
===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>

====Booting and logging in to the zone====
At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. Current testing shows no negative impact on [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm] based VistA installations.

Now your zone is ready to take for a spin. Even though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want. There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums [http://opensolaris.org/jive/index.jspa here]. The next section has some very brief information about installing VistA inside of the completed zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-10-29T20:14:25Z

Butch: /* Why I wrote this document, and why you should consider OpenSolaris */

==Document Scope==

This document describes how to set up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. That's a lower case "L" and is a reference to LinuX kernel 2.6 The goal is facilitating a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazon's EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document. If you would like information regarding the advanced virtualized networking features of OpenSolaris, check out the [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow project].

==Why I wrote this document, and why you should consider OpenSolaris==

Q. Why did I write this? 
A. Several reasons, here are a few of them.
* First and foremost, choice: OpenSolaris is a tool to be used in whatever endeavor you may want to tackle with it. In the context of this article, using it as a platform for VistA.
* To inform: Relatively few people know anything about OpenSolaris and even fewer even know that it exists. This is something I think that it shares with VistA. They are both extremely powerful software environments, and are so expansive that it would be nearly impossible for any one person to know everything. That very expansiveness fosters a community of users, from all parts of the world.
* To share: I have been using OpenSolaris for over a year now, and previously used Solaris 10 since 2007. I have gained a lot of experience with the OS, and think that I may be able to provide help and insight as to different ways to attack a given problem.

Q. Why should you consider OpenSolaris? 
A. I think a better question might be, why '''''shouldn't''''' you try OpenSolaris. If your reading this than you must be at least slightly interested, so here are a few reasons why you should try it.

* [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris] was designed from the beginning for enterprise computing.
* [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] "The last word in filesystems!"
* [http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit Dtrace] Wanna know what your program is doing? Add a couple of dtrace probes, and see things that have never been possible before.
* [http://hub.opensolaris.org/bin/view/Community+Group+xen/WebHome xVM] The OpenSolaris version of the popular Xen hypervisor.
* [http://hub.opensolaris.org/bin/view/Community+Group+zones/WebHome Zones/Containers]. OS level virtualization, zones allow for completely isolated instances for running software. This is similar to the xVM hypervisor in that it allows absolute containment of applications and utilities, the biggest difference being, xVM requires a separate kernel, and running operating system. Zones utilize a single operating system instance, and don't incur the overhead associated with a hypervisor based model. However, xVM and Zones are ''NOT'' mutually exclusive, and work quite well in parallel. Zones are the main focus of this document.
* Support: You can get help from the [http://opensolaris.org/jive/index.jspa forums], [http://www.sun.com/service/opensolaris/ support contracts] from Sun, and as with most any other question, [http://www.google.com Google] is an invaluable resource.
* [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome BrandZ]: An extension of the zone/container framework. Designed to support Linux applications on the OpenSolaris platform. People have run apps, ranging from Apache for Linux, to Unreal Tournament 2004 (playable with audio), to modern day game servers, to GT.M. There is a pretty high likelihood that if you can do it in Linux, you can do it in a zone/container.

==What this document is not==
This document is not meant to be the be-all-end-all of zone documentation. If you want to know more about lx26 zones in OpenSolaris, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

==What's needed==
Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation)
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is set aside for this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...

==Setting up the virtualization environment==

To enable lx26 zone support
===Download the template file===
<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>
===Create the zone===
This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>
===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>

====Booting and logging in to the zone====
At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. Current testing shows no negative impact on [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm] based VistA installations.

Now your zone is ready to take for a spin. Even though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want. There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums [http://opensolaris.org/jive/index.jspa here]. The next section has some very brief information about installing VistA inside of the completed zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-10-29T19:02:20Z

Butch: Added section Why I wrote this

==Document Scope==

This document describes how to set up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. That's a lower case "L" and is a reference to LinuX kernel 2.6 The goal is facilitating a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazon's EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document. If you would like information regarding the advanced virtualized networking features of OpenSolaris, check out the [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow project].

==Why I wrote this document, and why you should consider OpenSolaris==

==What this document is not==
This document is not meant to be the be-all-end-all of zone documentation. If you want to know more about lx26 zones in OpenSolaris, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

==What's needed==
Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation)
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is set aside for this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...

==Setting up the virtualization environment==

To enable lx26 zone support
===Download the template file===
<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>
===Create the zone===
This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>
===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>

====Booting and logging in to the zone====
At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. Current testing shows no negative impact on [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm] based VistA installations.

Now your zone is ready to take for a spin. Even though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want. There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums [http://opensolaris.org/jive/index.jspa here]. The next section has some very brief information about installing VistA inside of the completed zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-10-29T19:00:07Z

Butch: /* Finishing up */ Content edit

==Document Scope==

This document describes how to set up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. That's a lower case "L" and is a reference to LinuX kernel 2.6 The goal is facilitating a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazon's EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document. If you would like information regarding the advanced virtualized networking features of OpenSolaris, check out the [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow project].

==What this document is not==
This document is not meant to be the be-all-end-all of zone documentation. If you want to know more about lx26 zones in OpenSolaris, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

==What's needed==
Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation)
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is set aside for this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...

==Setting up the virtualization environment==

To enable lx26 zone support
===Download the template file===
<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>
===Create the zone===
This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>
===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>

====Booting and logging in to the zone====
At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. Current testing shows no negative impact on [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm] based VistA installations.

Now your zone is ready to take for a spin. Even though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want. There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums [http://opensolaris.org/jive/index.jspa here]. The next section has some very brief information about installing VistA inside of the completed zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-10-29T18:54:53Z

Butch: /* Finishing up */ Added hyperlink, edited text for content

==Document Scope==

This document describes how to set up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. That's a lower case "L" and is a reference to LinuX kernel 2.6 The goal is facilitating a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazon's EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document. If you would like information regarding the advanced virtualized networking features of OpenSolaris, check out the [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow project].

==What this document is not==
This document is not meant to be the be-all-end-all of zone documentation. If you want to know more about lx26 zones in OpenSolaris, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

==What's needed==
Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation)
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is set aside for this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...

==Setting up the virtualization environment==

To enable lx26 zone support
===Download the template file===
<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>
===Create the zone===
This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>
===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>

====Booting and logging in to the zone====
At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. Current testing shows no negative impact on [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm] based VistA installations.

Ok, that's it. Even though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want. There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums [http://opensolaris.org/jive/index.jspa here]. The next section has some very brief information about installing VistA inside of the completed zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-10-29T18:50:12Z

Butch: /* Pre-boot zone setup */Fixed line wrap

==Document Scope==

This document describes how to set up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. That's a lower case "L" and is a reference to LinuX kernel 2.6 The goal is facilitating a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazon's EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document. If you would like information regarding the advanced virtualized networking features of OpenSolaris, check out the [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow project].

==What this document is not==
This document is not meant to be the be-all-end-all of zone documentation. If you want to know more about lx26 zones in OpenSolaris, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

==What's needed==
Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation)
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is set aside for this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...

==Setting up the virtualization environment==

To enable lx26 zone support
===Download the template file===
<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>
===Create the zone===
This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>
===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>

====Booting and logging in to the zone====
At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system.

Ok, thats it. The zone is now usable for most anything you want to use it for. The next section has some very brief information about installing VistA inside a zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-10-29T18:48:22Z

Butch: /* What's needed */Added hyperlinks, edited text

==Document Scope==

This document describes how to set up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. That's a lower case "L" and is a reference to LinuX kernel 2.6 The goal is facilitating a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazon's EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document. If you would like information regarding the advanced virtualized networking features of OpenSolaris, check out the [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow project].

==What this document is not==
This document is not meant to be the be-all-end-all of zone documentation. If you want to know more about lx26 zones in OpenSolaris, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

==What's needed==
Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being a container is a zone with resource management tools applied. [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.

==Assumptions==
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation)
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is set aside for this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...

==Setting up the virtualization environment==

To enable lx26 zone support
===Download the template file===
<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>
===Create the zone===
This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>
===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration. I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>
====Booting and logging in to the zone====
At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system.

Ok, thats it. The zone is now usable for most anything you want to use it for. The next section has some very brief information about installing VistA inside a zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-10-29T18:42:57Z

Butch: /* Document Scope */Added hyperlinks and edited text

==Document Scope==

This document describes how to set up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris]. That's a lower case "L" and is a reference to LinuX kernel 2.6 The goal is facilitating a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazon's EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document. If you would like information regarding the advanced virtualized networking features of OpenSolaris, check out the [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow project].

==What this document is not==
This document is not meant to be the be-all-end-all of zone documentation. If you want to know more about lx26 zones in OpenSolaris, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

==What's needed==
Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.

==Assumptions==
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation)
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is set aside for this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...

==Setting up the virtualization environment==

To enable lx26 zone support
===Download the template file===
<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>
===Create the zone===
This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>
===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration. I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>
====Booting and logging in to the zone====
At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system.

Ok, thats it. The zone is now usable for most anything you want to use it for. The next section has some very brief information about installing VistA inside a zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-10-29T18:32:11Z

Butch: /* Assumptions */ Added hyperlinks and updated text

==Document Scope==

This document describes how to set up lx26 (that's a lower case "L" as in "Linux, kernel 26") zones on OpenSolaris, with the goal of installing a Linux based VistA implementation. This information applies to OpenSolaris on the x86, and x64 platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned RBAC privileges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazon's EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document. If you would like information regarding the advanced virtualized networking features of OpenSolaris, check out the [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow project].

==What this document is not==
This document is not meant to be the be-all-end-all of zone documentation. If you want to know more about lx26 zones in OpenSolaris, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

==What's needed==
Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.

==Assumptions==
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation)
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that is set aside for this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...

==Setting up the virtualization environment==

To enable lx26 zone support
===Download the template file===
<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>
===Create the zone===
This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>
===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration. I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>
====Booting and logging in to the zone====
At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system.

Ok, thats it. The zone is now usable for most anything you want to use it for. The next section has some very brief information about installing VistA inside a zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-10-29T18:28:30Z

Butch: /* What's needed */ Added new hyperlinks and expanded text

==Document Scope==

This document describes how to set up lx26 (that's a lower case "L" as in "Linux, kernel 26") zones on OpenSolaris, with the goal of installing a Linux based VistA implementation. This information applies to OpenSolaris on the x86, and x64 platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned RBAC privileges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazon's EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document. If you would like information regarding the advanced virtualized networking features of OpenSolaris, check out the [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow project].

==What this document is not==
This document is not meant to be the be-all-end-all of zone documentation. If you want to know more about lx26 zones in OpenSolaris, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

==What's needed==
Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here]. Note that 64-bit support is still in development and currently unstable.
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.

==Assumptions==
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation)
# You are using a network link aggregation (known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that set aside for this is 192.168.1.7/24, it is also the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...

==Setting up the virtualization environment==

To enable lx26 zone support
===Download the template file===
<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>
===Create the zone===
This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>
===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration. I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>
====Booting and logging in to the zone====
At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system.

Ok, thats it. The zone is now usable for most anything you want to use it for. The next section has some very brief information about installing VistA inside a zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-10-29T18:13:31Z

Butch: /* What this document is not */

==Document Scope==

This document describes how to set up lx26 (that's a lower case "L" as in "Linux, kernel 26") zones on OpenSolaris, with the goal of installing a Linux based VistA implementation. This information applies to OpenSolaris on the x86, and x64 platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned RBAC privileges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazon's EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document. If you would like information regarding the advanced virtualized networking features of OpenSolaris, check out the [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow project].

==What this document is not==
This document is not meant to be the be-all-end-all of zone documentation. If you want to know more about lx26 zones in OpenSolaris, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].

==What's needed==
Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. That can be gotten from the OpenVZ website. (64-bit support is still in the works and as far as I know unstable)
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.)
# You need to decide if you want the zones to start up on boot of the main system?
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.

==Assumptions==
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation)
# You are using a network link aggregation (known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that set aside for this is 192.168.1.7/24, it is also the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...

==Setting up the virtualization environment==

To enable lx26 zone support
===Download the template file===
<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>
===Create the zone===
This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>
===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration. I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>
====Booting and logging in to the zone====
At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system.

Ok, thats it. The zone is now usable for most anything you want to use it for. The next section has some very brief information about installing VistA inside a zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

OpenSolaris zones

2009-10-29T18:09:58Z

Butch: /* Document Scope */ added link for Crossbow

==Document Scope==

This document describes how to set up lx26 (that's a lower case "L" as in "Linux, kernel 26") zones on OpenSolaris, with the goal of installing a Linux based VistA implementation. This information applies to OpenSolaris on the x86, and x64 platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned RBAC privileges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazon's EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document. If you would like information regarding the advanced virtualized networking features of OpenSolaris, check out the [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow project].

==What this document is not==
This document is not meant to be the be-all-end-all of zone documentation. If you want to know more about zones in OpenSolaris go here: http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6

==What's needed==
Before beginning the install process you need several things, most of which are covered in this how-to:
# Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
# You need internet access on the machine where you will be doing the installation.
# You need to have a 32bit CentOS 5.x filesystem tarball. That can be gotten from the OpenVZ website. (64-bit support is still in the works and as far as I know unstable)
# You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances.
# You need to obtain a unique static IP address for each zone.
# You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.)
# You need to decide if you want the zones to start up on boot of the main system?
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.

==Assumptions==
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation)
# You are using a network link aggregation (known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
# The IP address that set aside for this is 192.168.1.7/24, it is also the IP that will be used throughout these examples.
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
# For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be.
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...

==Setting up the virtualization environment==

To enable lx26 zone support
===Download the template file===
<pre>
user@computer# cd /etc/zones
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml
</pre>
===Create the zone===
This section shows the commands to use, and the relative output:
<pre>
user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit
</pre>
===Install the zone:===

====Download and install a CentOS 5.x tarball====

<pre>
user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
</pre>
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

====Pre-boot zone setup====

Edit the following files to complete the networking setup:
<pre>
user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration. I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222
</pre>
====Booting and logging in to the zone====
At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.
<pre>
user@computer# zoneadm list
global
zone1
</pre>
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
<pre>
user@computer# zoneadm -z zone1 boot
</pre>
Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.
<pre>
user@computer# zlogin -S zone1
sh-3.2#
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way is to reset the root password to something of a known value.
<pre>
sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#
</pre>
===Finishing up===
You can at this point logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.
<pre>
sh-3.2# yum update
</pre>
This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system.

Ok, thats it. The zone is now usable for most anything you want to use it for. The next section has some very brief information about installing VistA inside a zone.

==OpenSolaris Zones and VistA installation overview==

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

===Nancy's installation instructions===
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.
===The Astronaut auto-installer===
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.
===The Medsphere installation method===
This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages.
'''NOTE:''' These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
[[User:Butch | Butch Whitby]]

User:Butch

2009-10-26T17:02:41Z

Butch:

My name is Butch Whitby. I've done a lot of things in my lifetime, including auto mechanics, carpentry, working on computers, and 5 years ago becoming a father.

I have been working with computers since I was around 8 years old. I went from playing Kings Quest III, on a dos machine, to learning how to use SCO UNIX, all before I was 10. I'm not even going to get into my experience with the Commodore 64...and that blasted program where you used the turtle to draw things on screen...then there was the Tandy, with the dual cassette drives...

Over the years I have learned a great deal about computers, and have played around with a lot of hardware, and operating systems. I use Windows strictly as a gaming platform, and even thats rare anymore. I have been through probably 2 or 3 dozen different Linux distros over the years. 2 years ago, I finally settled on Solaris 10 as my main OS, and more recently (November 2008) moved to OpenSolaris as my OS of choice.

I became aware and interested in VistA after meeting Steve Watson, in February 2009. I became a member of World VistA in June 2009, and have greatly enjoyed the networking, communication, and comradery with everyone else invloved.

VistA definitely has the potential to change medicine and the way that things are done. Of that there is no doubt. Getting it in a useable form, into the hands of the doctors who need it the most. That is the real challenge. What I mean by useable form, is when you consider that we live in a Windows world, and there is a GUI for everything...as soon as you present a command line to the average computer user, they are either going to laugh, cry, or ask you whats wrong with your head. That is the mindset that we often have to deal with. I don't mean VistA specifically either. I'm talking novice computer users in general.

Great strides are being made with VistA. I look forward to seeing the day when we succeed, and VistA is THE software of healthcare in the USA. Not because of a government mandate, that is only going to cause people to try and find something else, out of pure spite. Because VistA has become the most useable, well polished, and timesaving tool in the modern health practicioners arsenal, and they wouldn't work without it.

User:Butch

2009-10-26T16:59:59Z

Butch: Initial profile!

My name is Butch Whitby. I've done a lot of things in my lifetime, including auto mechanics, carpentry, working on computers, and 5 years ago becoming a father.

I have been working with computers since I was around 8 years old. I went from playing Kings Quest III, on a dos machine, to learning how to use SCO UNIX, all before I was 10. Over the years I have learned a great deal about computers, and have played around with a lot of hardware, and operating systems. I use Windows strictly as a gaming platform, and even thats rare anymore. I have been through probably 2 or 3 dozen different Linux distros over the years. 2 years ago, I finally settled on Solaris 10 as my main OS, and more recently (November 2008) moved to OpenSolaris as my OS of choice.

I became aware and interested in VistA after meeting Steve Watson, in February 2009. I became a member of World VistA in June 2009, and have greatly enjoyed the networking, communication, and comradery with everyone else invloved.

VistA definitely has the potential to change medicine and the way that things are done. Of that there is no doubt. Getting it in a useable form, into the hands of the doctors who need it the most. That is the real challenge. What I mean by useable form, is when you consider that we live in a Windows world, and there is a GUI for everything...as soon as you present a command line to the average computer user, they are either going to laugh, cry, or ask you whats wrong with your head. That is the mindset that we often have to deal with. I don't mean VistA specifically either. I'm talking novice computer users in general.

Great strides are being made with VistA. I look forward to seeing the day when we succeed, and VistA is THE software of healthcare in the USA. Not because of a government mandate, that is only going to cause people to try and find something else, out of pure spite. Because VistA has become the most useable, well polished, and timesaving tool in the modern health practicioners arsenal, and they wouldn't work without it.

Linux Active Directory How-To

2009-10-26T16:40:58Z

Butch: Fixed some formatting

Linux Active Directory How-To:

1. Document scope

This document briefly describes how to configure a GNU/Linux machine to authenticate users against a
Microsoft Windows Server 2003 Active Directory Server.

The idea behind this is to use Windows 2003 ADS (and possibly later versions) to authenticate a foreign user and allow him/her to use a Linux machine which is a member of the Windows domain, without having to create a user account manually on the Linux machine. This is very useful when you have large numbers of machines and users.

If everything works as it should, then you only need to configure the users on the Active Directory Server. The users can then walk up to any machine on the network and log on. If a user never used that machine before, a user account will be magically created. The magic trick is known as Single Sign-On (SSO).

The whole process is rather complicated and relies on a number of subsystems working together:
* Pluggable Authentication Modules (PAM)
* Server Message Block (SMB, Samba)
* WinBIND (part of Samba)
* Kerberos 5 (By MIT, with Microsoft compatibility hacks)

The biggest problem is configuring Samba and determining exactly what identifiers and spelling to use where, since Kerberos and NETBIOS are fond of uppercase, while everything else prefers lowercase.

Of course, nothing works, until every last little detail is correct, so these and other subtleties can lead to many hours of happy debugging and experimenting before everything suddenly begins to work.
Just about every imaginable error message was discovered the hard way and they were all documented in the references below. Of course, since you will be following this great guide, you wont ever see them - let's hope anyway.

Note that everything here was tested on Linux, but it should also apply almost directly to Solaris, since Samba is cross platform.

2. Referenced Documents

Chapter 6. Domain membership part II, Server configuration basics:
HTTP://us4.samba.org/samba/docs/man/samba-howto-collection/domain-member.html#ads-member

Chapter 24. Winbind: Use of Domain Accounts Part III. Advanced Configuration,
HTTP://us4.samba.org/samba/docs/man/samba-howto-collection/winbind.html

Kerberos Administration Guide, HTTP://web.mit.edu/kerberos/krb5-1.3/krb5-1.3/doc/krb5-admin.html

Linux PAM, HTTP://www.kernel.org/pub/linux/libs/pam3.

3. Configuration

We want to use the Windows 2003 Active Directory Server (ADS) to authenticate a foreign user and allow him or her to use a Linux machine which is a member of the Windows domain. Initially, the user jdoe doesn't exist on the Linux machine. We want to use Winbind and Samba to assign a UID and GID from a pool of reserve numbers and create a home directory automatically under /home/winnt for this foreign user. This will (hopefully) allow jdoe to walk up to the Linux machine, log in and use it to run X applications, without ever having been manually configured on it.

This guide assumes that you already have a Windows ADS running. First verify a few things on the Windows ADS machine and note that the NETBIOS work group must be uppercase:
<pre>
NETBIOS Workgroup: YOURWORKGROUPNAME
Domain name: example.com
Fully qualified domain host name: msads.example.com
User name defined in ADS: jdoe
User password: jdoe123
User primary group: winusergrp
Administrator name: Administrator
Administrator password: Supersecret
</pre>
This illustrates some weird points. Rather confusingly, the MS Windows NETBIOS work group, is also referred to as the domain name in MS Windows documentation. The NETBIOS work group is actually used more often than the real domain name, so when in doubt, use the NETBIOS work group, since it will usually be the correct one for the occasion.

The MS Windows user name, will become work group+user name on Linux, and the Windows primary group, will become the work group+group name on Linux.

3.1 Kerberos

Kerberos is configured in the file /etc/krb5.conf. Verify the following lines and not the UPPERCASE domain name:

<pre>
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM =
{
kdc = msads.example.com>
}
[domain_realms]
.kerberos.server = EXAMPLE.COM
</pre>

Note that Kerberos requires that the clocks of the machines in the domain are synchronized in time. The default maximum skew allowed is 5 minutes. Windows and Linux handle times differently. UNIX is UTC based, and Windows is local time zone based, so be careful. Configuring NTP is necessary, but is also beyond the scope of this document.

3.2 Nsswitch Configuration

Verify the following lines in /etc/nsswitch.conf:
<pre>
passwd: files winbind
shadow: files winbind
group: files winbind
</pre>
You may need to run ldconfig to set up the winbind libraries:

user@comp# ldconfig -v |grep winbind

Since nothing was working at the time, I cannot tell whether that was really a required step.

3.3 Samba configuration

Here's the [global] section from smb.conf:

<pre>
[global]
workgroup = YOURWORKGROUPNAME
realm = EXAMPLE.COM
preferred master = no
server string = Samba Server
security = ADS
encrypt passwords = yes
log level = 3
log file = /var/log/samba/%m
max log size = 50
winbind separator = +
printcap name = cups
printing = cups
idmap uid = 10000-20000
idmap gid = 10000-20000
template homedir /home/winnt/%D/%U
template shell = /bin/false
add machine script = /usr/sbin/useradd -d /var/lib/nobody -g 100 -s /bin/false -M %u
password server = msads.example.com
</pre>
The /bin/false shell will prevent foreign domain users from opening a command shell and is recommended for security.

The default Windind separator is a backslash, but that doesn't work well, since it is a reserve character on UNIX/Linux. The general rule is to change it to a '+'.

3.4 Ethernet configuration

You have to set the ADS machine as (one of) the DNS in /etc/resolv.conf, to enable the Linux machine to find the Kerberos and LDAP servers on the ADS. Verify the ethernet and DNS setting with ifconfig and nslookup.

3.5 Join the Domain

First restart the network and Samba:

user@comp # service network restart 
user@comp # service smb restart 

Verify that smbd and nmbd are running with

user@comp # ps e

Try to join the Windows Domain:

user@comp # net ads join -S msads.example.com -U administrator%Supersecret

You should get the message: "Joined LINUXMACHINE to realm EXAMPLE.COM", at which point most joyful celebrations are in order.

You can now start the Winbind daemon with the maximum debug information:

user@comp # winbindd -d 10

Watch /var/log/messages for errors:

user@comp # tail -f /var/log/messages

You can investigate the domain records with:

user@comp # wbinfo -u 
user@comp # whinfo -g 
user@comp # getent password 
user@comp # getent group 

With those utilities, you should be able to see the user names and groups in the domain that you just joined. User YOURWORKGROUPNAME+jdoe and the group
YOURWORKGROUPNAME+winusergrp should be listed.

3.6 Kerberos and error messages

If you get the message: Cannot find KDC for requested realm, then either the password server in smb.conf is wrong, or the DNS setting in resolv.conf is wrong.

If you get the message: KRB5 error code 68 while getting the initial credentials, then the Linux machine can talk to the ADS machine, but your Kerberos realm name in smb.conf is wrong.

If you get the message: The workgroup in smb.conf does not match the short domain name obtained from the server, then you did not specify the NETBIOS name properly.

-- 
[[User:Butch| Butch Whitby]]

OpenSolaris zones

2009-10-26T16:28:29Z

Butch: Added signature

Setting up an lx26 zone on OpenSolaris

Section 1.0 
Document Scope

This document describes how to setup lx26 zones on OpenSolaris, with the goal of installing a Linux based VistA implementation. This information applies to OpenSolaris on the x86, and x64 platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned RBAC priveleges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazons EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document.

Section 1.1 
What this document is not
This document is not meant to be the be all end all, of zone documentation. If you want to know more about zones in OpenSolaris go here: http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6

Section 1.2 
Whats needed
Before beginning the install process you need several things, most of which are covered in this how-to: 
1.Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking. 
2.You need internet access on the machine where you will be doing the installation. 
3.You need to have a 32bit CentOS 5.x filesystem tarball. That can be gotten from the OpenVZ website. (64-bit support is still in the works and as far as I know unstable) 
4.You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. 
5.You need to obtain a unique static IP address for each zone. 
6.You need to decide how your going to name your zones. Zones, are a method of virtualization, and should be treated as if they are individual systems. (IP, hostnames, etc.) 
7.You need to decide if you want the zones to start up on boot of the main system? 
8.You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to. 

Section 1.3 
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation) 
1.You are using a network link aggregation (known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0 
2.The IP address that set aside for this is 192.168.1.7/24, it is also the IP that will be used throughout these examples. 
3.The fs path I used for the zone files is, /zones ( I know it just reaks of creatvity :) ) 
4.For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone, whatever the hostname of the “virtual machine” will be. 
5.The CentOS 5.x tarball will be downloaded to /export/home/butch/software/ 
6.The username that I used for the demo is butch, cause using something other than my name seemed a tad silly... 
 
Section 2.0 
Setting up the virtualization environment

To enable lx26 zone support download the template file:

user@computer# cd /etc/zones 
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml 
user@computer# chown root:bin SUNWlx26.xml 
user@computer# chmod 444 SUNWlx26.xml 

Section 2.1 
Zone creation and installation
This section shows the commands to use, and the relative output:

user@computer# zonecfg -z zone1 
zone1: No such zone configured 
Use 'create' to begin configuring a new zone. 
zonecfg:zone1>create -t SUNWlx26 
zonecfg:zone1>set zonepath=/zones/zone1 
zonecfg:zone1>set autoboot=true 
zonecfg:zone1>add net 
zonecfg:zone1:net>set address=192.168.1.7/24 
zonecfg:zone1:net>set physical=aggr0 
zonecfg:zone1:net>end 
zonecfg:zone1>verify 
zonecfg:zone1>commit 
zonecfg:zone1>exit 
 
Installing the zone:

Download a CentOS 5.x tarball

user@computer# cd /export/home/butch/software/ 
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz 
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz 
Preparing to install zone <zone1>. 

Depending on your computers overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

Section 2.2 
Pre-boot zone setup.

Edit the following files to complete the networking setup:

user@computer# vi /zones/zone1/root/etc/sysconfig/network 
NETWORKING=yes 
HOSTNAME=zone1 
GATEWAY=192.168.1.1 
 
user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read) 
hosts: files dns nis 

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration. I used public nameservers for this demo.) 
domain opendns.org 
nameserver 208.67.220.220 
nameserver 208.67.222.222 

Section 2.3 
Booting and logging in to the zone

At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.

user@computer# zoneadm list
global
zone1

If zone1 is not listed in the output, then it's not yet running. To bring it online use:

user@computer# zoneadm -z zone1 boot

Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.

user@computer# zlogin -S zone1
sh-3.2#

At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way, is to reset the root password to something of a known value.

sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#

You can at this point, logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.

sh-3.2# yum update

This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system.

Ok, thats it. The zone is now useable for most anything you want to use it for. The next section has some very brief information about installing VistA inside a zone.

Section 3.0 
OpenSolaris Zones and VistA installation overview

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has it's place, and a time to use them. That decision however is up to the end user to decide.

Section 3.1 
Nancy's installation instructions 
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method. 
My thanks to Nancy for producing this document.

Section 3.2 
The Astronaut auto-installer 
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system. 
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.

Section 3.3 
The Medsphere installation method. 
This method, is similar to the Astronaut installation method, in that many of the tasks involved are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages, involves things like adding the EPEL software repo, as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medspheres packages. 
NOTE: These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment do not show any of these problems. Using these packages within a zone environment, is not how they were initially inteded to be used. I am working with the OpenSolaris community, as well as Medsphere to try and work these things out, but it's going to take time. 
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing this on OpenSolaris.

-- 
[[User:Butch | Butch Whitby]]

Linux Active Directory How-To

2009-10-26T16:27:38Z

Butch:

Linux Active Directory How-To:

1. Document scope

This document briefly describes how to configure a GNU/Linux machine to authenticate users against a
Microsoft Windows Server 2003 Active Directory Server.

The idea behind this is to use Windows 2003 ADS (and possibly later versions) to authenticate a foreign user and allow him/her to use a Linux machine which is a member of the Windows domain, without having to create a user account manually on the Linux machine. This is very useful when you have large numbers of machines and users.

If everything works as it should, then you only need to configure the users on the Active Directory Server. The users can then walk up to any machine on the network and log on. If a user never used that machine before, a user account will be magically created. The magic trick is known as Single Sign-On (SSO).

The whole process is rather complicated and relies on a number of subsystems working together:
Pluggable Authentication Modules (PAM)
Server Message Block (SMB, Samba)
WinBIND (part of Samba)
Kerberos 5 (By MIT, with Microsoft compatibility hacks)

The biggest problem is configuring Samba and determining exactly what identifiers and spelling to use where, since Kerberos and NETBIOS are fond of uppercase, while everything else prefers lowercase.

Of course, nothing works, until every last little detail is correct, so these and other subtleties can lead to many hours of happy debugging and experimenting before everything suddenly begins to work.
Just about every imaginable error message was discovered the hard way and they were all documented in the references below. Of course, since you will be following this great guide, you wont ever see them - let's hope anyway.

Note that everything here was tested on Linux, but it should also apply almost directly to Solaris, since Samba is cross platform.

2. Referenced Documents

Chapter 6. Domain membership part II, Server configuration basics:
HTTP://us4.samba.org/samba/docs/man/samba-howto-collection/domain-member.html#ads-member

Chapter 24. Winbind: Use of Domain Accounts Part III. Advanced Configuration,
HTTP://us4.samba.org/samba/docs/man/samba-howto-collection/winbind.html

Kerberos Administration Guide, HTTP://web.mit.edu/kerberos/krb5-1.3/krb5-1.3/doc/krb5-admin.html

Linux PAM, HTTP://www.kernel.org/pub/linux/libs/pam3.

3. Configuration

We want to use the Windows 2003 Active Directory Server (ADS) to authenticate a foreign user and allow him or her to use a Linux machine which is a member of the Windows domain. Initially, the user jdoe doesn't exist on the Linux machine. We want to use Winbind and Samba to assign a UID and GID from a pool of reserve numbers and create a home directory automatically under /home/winnt for this foreign user. This will (hopefully) allow jdoe to walk up to the Linux machine, log in and use it to run X applications, without ever having been manually configured on it.

This guide assumes that you already have a Windows ADS running. First verify a few things on the Windows ADS machine and note that the NETBIOS work group must be uppercase:
NETBIOS Workgroup: YOURWORKGROUPNAME
Domain name: example.com
Fully qualified domain host name: msads.example.com
User name defined in ADS: jdoe
User password: jdoe123
User primary group: winusergrp
Administrator name: Administrator
Administrator password: Supersecret

This illustrates some weird points. Rather confusingly, the MS Windows NETBIOS work group, is also referred to as the domain name in MS Windows documentation. The NETBIOS work group is actually used more often than the real domain name, so when in doubt, use the NETBIOS work group, since it will usually be the correct one for the occasion.

The MS Windows user name, will become work group+user name on Linux, and the Windows primary group, will become the work group+group name on Linux.

3.1 Kerberos

Kerberos is configured in the file /etc/krb5.conf. Verify the following lines and not the UPPERCASE domain name:

[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM =
{
kdc = msads.example.com>
}
[domain_realms]
.kerberos.server = EXAMPLE.COM

Note that Kerberos requires that the clocks of the machines in the domain are synchronized in time. The default maximum skew allowed is 5 minutes. Windows and Linux handle times differently. UNIX is UTC based, and Windows is local time zone based, so be careful. Configuring NTP is necessary, but is also beyond the scope of this document.

3.2 Nsswitch Configuration

Verify the following lines in /etc/nsswitch.conf:

passwd: files winbind
shadow: files winbind
group: files winbind

You may need to run ldconfig to set up the winbind libraries:

# ldconfig -v |grep winbind

Since nothing was working at the time, I cannot tell whether that was really a required step.

3.3 Samba configuration

Here's the [global] section from smb.conf:

[global]
workgroup = YOURWORKGROUPNAME
realm = EXAMPLE.COM
preferred master = no
server string = Samba Server
security = ADS
encrypt passwords = yes
log level = 3
log file = /var/log/samba/%m
max log size = 50
winbind separator = +
printcap name = cups
printing = cups
idmap uid = 10000-20000
idmap gid = 10000-20000
template homedir /home/winnt/%D/%U
template shell = /bin/false
add machine script = /usr/sbin/useradd -d /var/lib/nobody -g 100 -s /bin/false -M %u
password server = msads.example.com

The /bin/false shell will prevent foreign domain users from opening a command shell and is recommended for security.

The default Windind separator is a backslash, but that doesn't work well, since it is a reserve character on UNIX/Linux. The general rule is to change it to a '+'.

3.4 Ethernet configuration

You have to set the ADS machine as (one of) the DNS in /etc/resolv.conf, to enable the Linux machine to find the Kerberos and LDAP servers on the ADS. Verify the ethernet and DNS setting with ifconfig and nslookup.

3.5 Join the Domain

First restart the network and Samba:

# service network restart
# service smb restart

Verify that smbd and nmbd are running with

# ps e

Try to join the Windows Domain:

# net ads join -S msads.example.com -U administrator%Supersecret

You should get the message: "Joined LINUXMACHINE to realm EXAMPLE.COM", at which point most joyful celebrations are in order.

You can now start the Winbind daemon with the maximum debug information:

# winbindd -d 10

Watch /var/log/messages for errors:

# tail -f /var/log/messages

You can investigate the domain records with:

# wbinfo -u
# whinfo -g
# getent password
# getent group

With those utilities, you should be able to see the user names and groups in the domain that you just
joined. User YOURWORKGROUPNAME+jdoe and the group
YOURWORKGROUPNAME+winusergrp should be listed.

3.6 Kerberos and error messages

If you get the message: Cannot find KDC for requested realm, then either the password server in smb.conf is wrong, or the DNS setting in resolv.conf is wrong.

If you get the message: KRB5 error code 68 while getting the initial credentials, then the Linux machine can talk to the ADS machine, but your Kerberos realm name in smb.conf is wrong.

If you get the message: The workgroup in smb.conf does not match the short domain name obtained from the server, then you did not specify the NETBIOS name properly.

-- 
[[User:Butch| Butch Whitby]]

Linux Active Directory How-To

2009-10-26T16:27:18Z

Butch: Added signature

Linux Active Directory How-To:

1. Document scope

This document briefly describes how to configure a GNU/Linux machine to authenticate users against a
Microsoft Windows Server 2003 Active Directory Server.

The idea behind this is to use Windows 2003 ADS (and possibly later versions) to authenticate a foreign user and allow him/her to use a Linux machine which is a member of the Windows domain, without having to create a user account manually on the Linux machine. This is very useful when you have large numbers of machines and users.

If everything works as it should, then you only need to configure the users on the Active Directory Server. The users can then walk up to any machine on the network and log on. If a user never used that machine before, a user account will be magically created. The magic trick is known as Single Sign-On (SSO).

The whole process is rather complicated and relies on a number of subsystems working together:
Pluggable Authentication Modules (PAM)
Server Message Block (SMB, Samba)
WinBIND (part of Samba)
Kerberos 5 (By MIT, with Microsoft compatibility hacks)

The biggest problem is configuring Samba and determining exactly what identifiers and spelling to use where, since Kerberos and NETBIOS are fond of uppercase, while everything else prefers lowercase.

Of course, nothing works, until every last little detail is correct, so these and other subtleties can lead to many hours of happy debugging and experimenting before everything suddenly begins to work.
Just about every imaginable error message was discovered the hard way and they were all documented in the references below. Of course, since you will be following this great guide, you wont ever see them - let's hope anyway.

Note that everything here was tested on Linux, but it should also apply almost directly to Solaris, since Samba is cross platform.

2. Referenced Documents

Chapter 6. Domain membership part II, Server configuration basics:
HTTP://us4.samba.org/samba/docs/man/samba-howto-collection/domain-member.html#ads-member

Chapter 24. Winbind: Use of Domain Accounts Part III. Advanced Configuration,
HTTP://us4.samba.org/samba/docs/man/samba-howto-collection/winbind.html

Kerberos Administration Guide, HTTP://web.mit.edu/kerberos/krb5-1.3/krb5-1.3/doc/krb5-admin.html

Linux PAM, HTTP://www.kernel.org/pub/linux/libs/pam3.

3. Configuration

We want to use the Windows 2003 Active Directory Server (ADS) to authenticate a foreign user and allow him or her to use a Linux machine which is a member of the Windows domain. Initially, the user jdoe doesn't exist on the Linux machine. We want to use Winbind and Samba to assign a UID and GID from a pool of reserve numbers and create a home directory automatically under /home/winnt for this foreign user. This will (hopefully) allow jdoe to walk up to the Linux machine, log in and use it to run X applications, without ever having been manually configured on it.

This guide assumes that you already have a Windows ADS running. First verify a few things on the Windows ADS machine and note that the NETBIOS work group must be uppercase:
NETBIOS Workgroup: YOURWORKGROUPNAME
Domain name: example.com
Fully qualified domain host name: msads.example.com
User name defined in ADS: jdoe
User password: jdoe123
User primary group: winusergrp
Administrator name: Administrator
Administrator password: Supersecret

This illustrates some weird points. Rather confusingly, the MS Windows NETBIOS work group, is also referred to as the domain name in MS Windows documentation. The NETBIOS work group is actually used more often than the real domain name, so when in doubt, use the NETBIOS work group, since it will usually be the correct one for the occasion.

The MS Windows user name, will become work group+user name on Linux, and the Windows primary group, will become the work group+group name on Linux.

3.1 Kerberos

Kerberos is configured in the file /etc/krb5.conf. Verify the following lines and not the UPPERCASE domain name:

[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM =
{
kdc = msads.example.com>
}
[domain_realms]
.kerberos.server = EXAMPLE.COM

Note that Kerberos requires that the clocks of the machines in the domain are synchronized in time. The default maximum skew allowed is 5 minutes. Windows and Linux handle times differently. UNIX is UTC based, and Windows is local time zone based, so be careful. Configuring NTP is necessary, but is also beyond the scope of this document.

3.2 Nsswitch Configuration

Verify the following lines in /etc/nsswitch.conf:

passwd: files winbind
shadow: files winbind
group: files winbind

You may need to run ldconfig to set up the winbind libraries:

# ldconfig -v |grep winbind

Since nothing was working at the time, I cannot tell whether that was really a required step.

3.3 Samba configuration

Here's the [global] section from smb.conf:

[global]
workgroup = YOURWORKGROUPNAME
realm = EXAMPLE.COM
preferred master = no
server string = Samba Server
security = ADS
encrypt passwords = yes
log level = 3
log file = /var/log/samba/%m
max log size = 50
winbind separator = +
printcap name = cups
printing = cups
idmap uid = 10000-20000
idmap gid = 10000-20000
template homedir /home/winnt/%D/%U
template shell = /bin/false
add machine script = /usr/sbin/useradd -d /var/lib/nobody -g 100 -s /bin/false -M %u
password server = msads.example.com

The /bin/false shell will prevent foreign domain users from opening a command shell and is recommended for security.

The default Windind separator is a backslash, but that doesn't work well, since it is a reserve character on UNIX/Linux. The general rule is to change it to a '+'.

3.4 Ethernet configuration

You have to set the ADS machine as (one of) the DNS in /etc/resolv.conf, to enable the Linux machine to find the Kerberos and LDAP servers on the ADS. Verify the ethernet and DNS setting with ifconfig and nslookup.

3.5 Join the Domain

First restart the network and Samba:

# service network restart
# service smb restart

Verify that smbd and nmbd are running with

# ps e

Try to join the Windows Domain:

# net ads join -S msads.example.com -U administrator%Supersecret

You should get the message: "Joined LINUXMACHINE to realm EXAMPLE.COM", at which point most joyful celebrations are in order.

You can now start the Winbind daemon with the maximum debug information:

# winbindd -d 10

Watch /var/log/messages for errors:

# tail -f /var/log/messages

You can investigate the domain records with:

# wbinfo -u
# whinfo -g
# getent password
# getent group

With those utilities, you should be able to see the user names and groups in the domain that you just
joined. User YOURWORKGROUPNAME+jdoe and the group
YOURWORKGROUPNAME+winusergrp should be listed.

3.6 Kerberos and error messages

If you get the message: Cannot find KDC for requested realm, then either the password server in smb.conf is wrong, or the DNS setting in resolv.conf is wrong.

If you get the message: KRB5 error code 68 while getting the initial credentials, then the Linux machine can talk to the ADS machine, but your Kerberos realm name in smb.conf is wrong.

If you get the message: The workgroup in smb.conf does not match the short domain name obtained from the server, then you did not specify the NETBIOS name properly.

--
[[User:Butch| Butch Whitby]]

OpenSolaris zones

2009-10-26T16:17:23Z

Butch: Updating formatting

OpenSolaris zones

2009-10-26T16:15:27Z

Butch: More markup and formatting updates.

Setting up an lx26 zone on OpenSolaris

Section 1.0 
Document Scope

This document describes how to setup lx26 zones on OpenSolaris, with the goal of installing a Linux based VistA implementation. This information applies to OpenSolaris on the x86, and x64 platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned RBAC priveleges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazons EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document.

Section 1.1 
What this document is not
This document is not meant to be the be all end all, of zone documentation. If you want to know more about zones in OpenSolaris go here: http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6

Section 1.2 
Whats needed
Before beginning the install process you need several things, most of which are covered in this how-to: 
1.Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking. 
2.You need internet access on the machine where you will be doing the installation. 
3.You need to have a 32bit CentOS 5.x filesystem tarball. That can be gotten from the OpenVZ website. (64-bit support is still in the works and as far as I know unstable) 
4.You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. 
5.You need to obtain a unique static IP address for each zone. 
6.You need to decide how your going to name your zones. Zones, are a method of virtualization, and should be treated as if they are individual systems. (IP, hostnames, etc.) 
7.You need to decide if you want the zones to start up on boot of the main system? 
8.You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to. 

Section 1.3 
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation) 
1.You are using a network link aggregation (known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0 
2.The IP address that set aside for this is 192.168.1.7/24, it is also the IP that will be used throughout these examples. 
3.The fs path I used for the zone files is, /zones ( I know it just reaks of creatvity :) ) 
4.For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone, whatever the hostname of the “virtual machine” will be. 
5.The CentOS 5.x tarball will be downloaded to /export/home/butch/software/ 
6.The username that I used for the demo is butch, cause using something other than my name seemed a tad silly... 
 
Section 2.0 
Setting up the virtualization environment

To enable lx26 zone support download the template file:

user@computer# cd /etc/zones 
user@computer# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml 
user@computer# chown root:bin SUNWlx26.xml 
user@computer# chmod 444 SUNWlx26.xml 

Section 2.1 
Zone creation and installation
This section shows the commands to use, and the relative output:

user@computer# zonecfg -z zone1 
zone1: No such zone configured 
Use 'create' to begin configuring a new zone. 
zonecfg:zone1>create -t SUNWlx26 
zonecfg:zone1>set zonepath=/zones/zone1 
zonecfg:zone1>set autoboot=true 
zonecfg:zone1>add net 
zonecfg:zone1:net>set address=192.168.1.7/24 
zonecfg:zone1:net>set physical=aggr0 
zonecfg:zone1:net>end 
zonecfg:zone1>verify 
zonecfg:zone1>commit 
zonecfg:zone1>exit 
 
Installing the zone:

Download a CentOS 5.x tarball

user@computer# cd /export/home/butch/software/ 
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz 
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz 
Preparing to install zone <zone1>. 

Depending on your computers overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

Section 2.2 
Pre-boot zone setup.

Edit the following files to complete the networking setup:

user@computer# vi /zones/zone1/root/etc/sysconfig/network 
NETWORKING=yes 
HOSTNAME=zone1 
GATEWAY=192.168.1.1 
 
user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read) 
hosts: files dns nis 

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration. I used public nameservers for this demo.) 
domain opendns.org 
nameserver 208.67.220.220 
nameserver 208.67.222.222 

Section 2.3 
Booting and logging in to the zone

At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.

user@computer# zoneadm list
global
zone1

If zone1 is not listed in the output, then it's not yet running. To bring it online use:

user@computer# zoneadm -z zone1 boot

Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.

user@computer# zlogin -S zone1
sh-3.2#

At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way, is to reset the root password to something of a known value.

sh-3.2# passwd root

Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
sh-3.2#

You can at this point, logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.

sh-3.2# yum update

This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system.

Ok, thats it. The zone is now useable for most anything you want to use it for. The next section has some very brief information about installing VistA inside a zone.

Section 3.0 
OpenSolaris Zones and VistA installation overview

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has it's place, and a time to use them. That decision however is up to the end user to decide.

Section 3.1 
Nancy's installation instructions
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.

Section 3.2 
The Astronaut auto-installer
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.

Section 3.3 
The Medsphere installation method.
This method, is similar to the Astronaut installation method, in that many of the tasks involved are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages, involves things like adding the EPEL software repo, as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medspheres packages.
NOTE: These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment do not show any of these problems. Using these packages within a zone environment, is not how they were initially inteded to be used. I am working with the OpenSolaris community, as well as Medsphere to try and work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing this on OpenSolaris.

OpenSolaris zones

2009-10-26T16:04:38Z

Butch: Cleaned up page layout

Setting up an lx26 zone on OpenSolaris

Section 1.0 
Document Scope

This document describes how to setup lx26 zones on OpenSolaris, with the goal of installing a Linux based VistA implementation. This information applies to OpenSolaris on the x86, and x64 platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned RBAC priveleges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazons EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document.

Section 1.1 
What this document is not
This document is not meant to be the be all end all, of zone documentation. If you want to know more about zones in OpenSolaris go here: http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6

Section 1.2 
Whats needed
Before beginning the install process you need several things, most of which are covered in this how-to:
1.Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
2.You need internet access on the machine where you will be doing the installation.
3.You need to have a 32bit CentOS 5.x filesystem tarball. That can be gotten from the OpenVZ website. (64-bit support is still in the works and as far as I know unstable)
4.You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances.
5.You need to obtain a unique static IP address for each zone.
6.You need to decide how your going to name your zones. Zones, are a method of virtualization, and should be treated as if they are individual systems. (IP, hostnames, etc.)
7.You need to decide if you want the zones to start up on boot of the main system?
8.You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.

Section 1.3 
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation)
1.You are using a network link aggregation (known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
2.The IP address that set aside for this is 192.168.1.7/24, it is also the IP that will be used throughout these examples.
3.The fs path I used for the zone files is, /zones ( I know it just reaks of creatvity :) )
4.For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone, whatever the hostname of the “virtual machine” will be.
5.The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
6.The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...

Section 2.0 
Setting up the virtualization environment

To enable lx26 zone support download the template file:

# cd /etc/zones
# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
# chown root:bin SUNWlx26.xml
# chmod 444 SUNWlx26.xml

Section 2.1 
Zone creation and installation
This section shows the commands to use, and the relative output:

# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit

Installing the zone:

Download a CentOS 5.x tarball

# cd /export/home/butch/software/
# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.

Depending on your computers overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

Section 2.2 
Pre-boot zone setup.

Edit the following files to complete the networking setup:

# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration. I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222

Section 2.3 
Booting and logging in to the zone

At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.

# zoneadm list
global
zone1

If zone1 is not listed in the output, then it's not yet running. To bring it online use:

# zoneadm -z zone1 boot

Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.

# zlogin -S zone1
sh-3.2#

At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way, is to reset the root password to something of a known value.

sh-3.2# passwd root

Changing password for user root.

New UNIX password:

Retype new UNIX password:

passwd: all authentication tokens updated successfully.

sh-3.2#

You can at this point, logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.

sh-3.2# yum update

This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system.

Ok, thats it. The zone is now useable for most anything you want to use it for. The next section has some very brief information about installing VistA inside a zone.

Section 3.0 
OpenSolaris Zones and VistA installation overview

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has it's place, and a time to use them. That decision however is up to the end user to decide.

Section 3.1 
Nancy's installation instructions
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.

Section 3.2 
The Astronaut auto-installer
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.

Section 3.3 
The Medsphere installation method.
This method, is similar to the Astronaut installation method, in that many of the tasks involved are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages, involves things like adding the EPEL software repo, as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medspheres packages.
NOTE: These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment do not show any of these problems. Using these packages within a zone environment, is not how they were initially inteded to be used. I am working with the OpenSolaris community, as well as Medsphere to try and work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing this on OpenSolaris.

OpenSolaris zones

2009-10-26T16:02:34Z

Butch: Edited page markup

Setting up an lx26 zone on OpenSolaris

Section 1.0 
Document Scope

This document describes how to setup lx26 zones on OpenSolaris, with the goal of installing a Linux based VistA implementation. This information applies to OpenSolaris on the x86, and x64 platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned RBAC priveleges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazons EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document.

1.1 
What this document is not
This document is not meant to be the be all end all, of zone documentation. If you want to know more about zones in OpenSolaris go here: http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6

1.2 
Whats needed
Before beginning the install process you need several things, most of which are covered in this how-to:
1.Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
2.You need internet access on the machine where you will be doing the installation.
3.You need to have a 32bit CentOS 5.x filesystem tarball. That can be gotten from the OpenVZ website. (64-bit support is still in the works and as far as I know unstable)
4.You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances.
5.You need to obtain a unique static IP address for each zone.
6.You need to decide how your going to name your zones. Zones, are a method of virtualization, and should be treated as if they are individual systems. (IP, hostnames, etc.)
7.You need to decide if you want the zones to start up on boot of the main system?
8.You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.

1.3 
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation)
1.You are using a network link aggregation (known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
2.The IP address that set aside for this is 192.168.1.7/24, it is also the IP that will be used throughout these examples.
3.The fs path I used for the zone files is, /zones ( I know it just reaks of creatvity :) )
4.For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone, whatever the hostname of the “virtual machine” will be.
5.The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
6.The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...

Section 2.0 
Setting up the virtualization environment

To enable lx26 zone support download the template file:

# cd /etc/zones
# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
# chown root:bin SUNWlx26.xml
# chmod 444 SUNWlx26.xml

2.1 
Zone creation and installation
This section shows the commands to use, and the relative output:

# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit

Installing the zone:

Download a CentOS 5.x tarball

# cd /export/home/butch/software/
# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.

Depending on your computers overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

2.2 
Pre-boot zone setup.

Edit the following files to complete the networking setup:

# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration. I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222

2.3 
Booting and logging in to the zone

At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.

# zoneadm list
global
zone1

If zone1 is not listed in the output, then it's not yet running. To bring it online use:

# zoneadm -z zone1 boot

Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.

# zlogin -S zone1
sh-3.2#

At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way, is to reset the root password to something of a known value.

sh-3.2# passwd root

Changing password for user root.

New UNIX password:

Retype new UNIX password:

passwd: all authentication tokens updated successfully.

sh-3.2#

You can at this point, logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.

sh-3.2# yum update

This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system.

Ok, thats it. The zone is now useable for most anything you want to use it for. The next section has some very brief information about installing VistA inside a zone.

Section 3.0 
OpenSolaris Zones and VistA installation overview

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has it's place, and a time to use them. That decision however is up to the end user to decide.

3.1 
Nancy's installation instructions
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.

3.2 
The Astronaut auto-installer
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.

3.3 
The Medsphere installation method.
This method, is similar to the Astronaut installation method, in that many of the tasks involved are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages, involves things like adding the EPEL software repo, as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medspheres packages.
NOTE: These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment do not show any of these problems. Using these packages within a zone environment, is not how they were initially inteded to be used. I am working with the OpenSolaris community, as well as Medsphere to try and work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing this on OpenSolaris.

OpenSolaris zones

2009-10-26T16:00:03Z

Butch:

Setting up an lx26 zone on OpenSolaris

Section 1.0
Document Scope

This document describes how to setup lx26 zones on OpenSolaris, with the goal of installing a Linux based VistA implementation. This information applies to OpenSolaris on the x86, and x64 platforms. SPARC based systems are not covered.

This document assumes several things, including that you have either root level access, or you have been assigned RBAC priveleges for zones on an OpenSolaris machine.

When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisors. In the latter cases I will refer to them by name.

Something else worth noting. This will not likely work on Amazons EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own. There are ways to work around this, however the details of such things are well beyond the scope or intent of this document.

1.1) What this document is not
This document is not meant to be the be all end all, of zone documentation. If you want to know more about zones in OpenSolaris go here: http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6

1.2) Whats needed
Before beginning the install process you need several things, most of which are covered in this how-to:
1.Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
2.You need internet access on the machine where you will be doing the installation.
3.You need to have a 32bit CentOS 5.x filesystem tarball. That can be gotten from the OpenVZ website. (64-bit support is still in the works and as far as I know unstable)
4.You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances.
5.You need to obtain a unique static IP address for each zone.
6.You need to decide how your going to name your zones. Zones, are a method of virtualization, and should be treated as if they are individual systems. (IP, hostnames, etc.)
7.You need to decide if you want the zones to start up on boot of the main system?
8.You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover the 3 at the end of this how-to.

1.3)
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation)
1.You are using a network link aggregation (known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
2.The IP address that set aside for this is 192.168.1.7/24, it is also the IP that will be used throughout these examples.
3.The fs path I used for the zone files is, /zones ( I know it just reaks of creatvity :) )
4.For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone, whatever the hostname of the “virtual machine” will be.
5.The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
6.The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...

Section 2.0
Setting up the virtualization environment

To enable lx26 zone support download the template file:

# cd /etc/zones
# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
# chown root:bin SUNWlx26.xml
# chmod 444 SUNWlx26.xml

2.1) Zone creation and installation
This section shows the commands to use, and the relative output:

# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit

Installing the zone:

Download a CentOS 5.x tarball

# cd /export/home/butch/software/
# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.

Depending on your computers overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

2.2) Pre-boot zone setup.

Edit the following files to complete the networking setup:

# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration. I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222

2.3) Booting and logging in to the zone

At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.

# zoneadm list
global
zone1

If zone1 is not listed in the output, then it's not yet running. To bring it online use:

# zoneadm -z zone1 boot

Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.

# zlogin -S zone1
sh-3.2#

At this point, you have a login that resembles a Linux run level 1 command prompt. The reason for logging in this way, is to reset the root password to something of a known value.

sh-3.2# passwd root

Changing password for user root.

New UNIX password:

Retype new UNIX password:

passwd: all authentication tokens updated successfully.

sh-3.2#

You can at this point, logout and ssh back into the machine, although it's not really necessary to do what needs doing. Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.

sh-3.2# yum update

This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system.

Ok, thats it. The zone is now useable for most anything you want to use it for. The next section has some very brief information about installing VistA inside a zone.

Section 3.0
OpenSolaris Zones and VistA installation overview

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has it's place, and a time to use them. That decision however is up to the end user to decide.

3.1) Nancy's installation instructions
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly. Cut and paste will be your friend with this method.
My thanks to Nancy for producing this document.

3.2) The Astronaut auto-installer
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system.
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view.

3.3) The Medsphere installation method.
This method, is similar to the Astronaut installation method, in that many of the tasks involved are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages, involves things like adding the EPEL software repo, as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medspheres packages.
NOTE: These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment do not show any of these problems. Using these packages within a zone environment, is not how they were initially inteded to be used. I am working with the OpenSolaris community, as well as Medsphere to try and work these things out, but it's going to take time.
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing this on OpenSolaris.