Patching at Install Time 4.1.1

yehster wrote on Monday, April 01, 2013:

Can anyone think of issues if we were to change the distributed package to mirror the files of the stable development files in git  (e.g. rel-411 patch 12 at present…) then on the last screen of the install, provide a link directly to the sql_patch.php page?

Am I missing anything towards the goal of having new OpenEMR installations be more secure “out of the box?”

tmccormi wrote on Tuesday, April 02, 2013:

Are you saying to have the installation pull the files from Git and then the Patch?  Or to have the ZIP/TAR and DEB created live from the git and then patch itself or what?   Not sure I’m understanding what you mean.

Tony
www.mi-squared.com / @MI2_OpenEMR
oemr.org / @OEMR_org

yehster wrote on Tuesday, April 02, 2013:

I am suggesting that the contents of the zip/tar files available for download ought to be updated to be identical to what you would get if you were to pull rel-411 patch 12 from git (all of the files, not just the patch).

I’m actually realizing that the extra step of going to the “sql_patch.php” screen isn’t necessary because any such changes are already in the database.sql file.

Put another way,
Step 1. Checkout the rel-411 HEAD on my computer, and create a zip file from that directory. 
Step 2. Host that zip file on a web site.
Step 3. Someone else downloads that zip file, unzips it and runs the install script.

At this point, doesn’t that someone else have a fully patched system?

bradymiller wrote on Tuesday, April 02, 2013:

Hi,

Yes, that can be done. Note that the developers demo (including the 4.1.1 one) actually builds these packages daily as part of their scripts (this is where the daily zip/tar developer package on the download page come from).

Couple things to think about though:
1. We currently have several very easy to install packages (XAMPP,ubuntu,appliance) which make it very easy for potential users to install/trial the software (Note that the xampp package is the most downloaded package; even more than the zip package). By offering official releases with each patch, we won’t be able to support the xampp/ubuntu/appliance releases for each patch. And this experiment has already been tried; for example, in one of the past releases, a xampp package wasn’t released and we ended up spending lots of time telling people how to download the previous xampp version and then upgrade it. So, essentially, most new users will still download the xampp 4.1.1 version without the patch and need to upgrade it to the new patch anyways.

2. We currently have excellent installation documentation (on the open-emr.org site at least) that tells people how to install the package(and where to download it), and direct them to the patch and security pages. With each version release these instructions can change, and it could even change mid-patch (ie. this means more resources).

3. A patch generally takes several hours to release depending on the complexity and testing needed. By making it a release will place more burden on the patcher (ie. myself); for example, if documentation will be effected somewhere etc…

4. My view of a release is sort of similar to publishing an article/book. There are many pieces involved that take a lot of resources to accomplish (things like testing demo, zip/tar/ubuntu/appliance/xampp packages and the documentation). This release then provides a solid foundation for new users to install and try the product. If a new user can’t install it on the first attempt, then you will generally lose that new user. You will not lose that new user if they install, like it, but then after they’ve already been hooked, they found out there are “out of the box” security issues and they need to install a patch to fix a security issue.

Related to this topic, here is some very easy low hanging fruit to address the security issue:
1. Place a link to the patch page on the last openemr installation step screen.
2. Remove all unmaintained content regarding installation instructions, patches, downloads, security from the oemr.org wiki.

-brady
OpenEMR

robertrambo wrote on Tuesday, April 02, 2013:

Hi Brady

What is the #openemr schedule is there a time and agenda for the irc?
Members only?

-Rob

bradymiller wrote on Tuesday, April 02, 2013:

Hi Rob,

The irc is open to anybody and is on 24 hours day, 7 days a week. Setting up a weekly meeting or something like that sounds like a good idea though. It could be as a companion to the Tuesday AM conference calls.

Here is the irc channel:
irc://testnet.freenode.net/#openemr

-brady
OpenEMR

robertrambo wrote on Tuesday, April 02, 2013:

Hi

I hope that one day it is automated with a package manager that is says you need to install an important update.
I have seen people running around with un patched systems for over a month. I have also heard of alot of botched installs due to lack of proper mysql upgrades etc here on the forum. Of course there is the issue of customized files for unique installs these could be caught with hashes on the pre install then user prompted to skip?

I am a fan of your approach here Brady ->
2. Remove all unmaintained content regarding installation instructions, patches, downloads, security from the oemr.org wiki.

Then its a no brainer no patches only latest stable release

-Rob

bradymiller wrote on Tuesday, April 02, 2013:

Hi Rob,

To not confuse things, note that the content on the open-emr.org wiki is maintained and updated.

A patching mechanism is needed. It has allowed us to get bug fixes, security fixes and sometimes even new feature in high demand to folks without needing to expend the effort it takes to issue a release. The current patching mechanism does the job with minimal resources. Of course, this could always be improved; but it requires more than planning and thought (ie. real work is needed to build the mechanism and real work is required to maintain the mechanism; if anybody is up to the task, then please build it :slight_smile: ).

-brady
OpenEMR

yehster wrote on Thursday, April 04, 2013:

In a world with infinite resources, a good place to spend some of them might be to develop some additional tools/automation for the package/patch/release process.  Ideally we could more easily update the XAMPP/ubuntu/appliance packages by just executing a script, instead of it being the involved manual process I imagine it is today.

Realistically, I know this isn’t going to happen any time soon, but we can hope.

I’m realizing that those who download the preinstalled XAMPP package or the Appliance don’t see the “install pages” so a message to upgrade there won’t help them.  Perhaps we could add a message at “first login” to the system directing users to look for a patch.

blankev wrote on Thursday, April 04, 2013:

Although I am surethat PROCEDURES are in need of a more practical approach and solutions for input and results in OpenEMR, it could be that you can give me the information I am looking ofr.

Suppose I make a general SQL file with procedures basics, someethin like Hematology, Urine tests, Radiology, Chemistry, would there be a place I can get it in OpenEMR release in due time like tere is a standard for parts of prcedures in the LIST options to be used with PROCEDURES?

Is there a place in GitHUB or do I need to get thins in SQL format and have this inculujded through a patch or new release made by future OpenEMR Developers?

Please advise. If needed I can give more info about the idea.

Pimm

robertrambo wrote on Friday, April 05, 2013:

Hi Brady

Yehster has a great idea I hope this does not get lost in the todo list, I would like to follow up on this in the not too distant future when I have some more time. Would you share the automated build process (zip script?)I am not familiar as you both are?
I would be willing to work on the auto package on a limited basis.
I have also looked at this https://sourceforge.net/tracker/?func=rssfeed&group_id=60081

-Rob

bradymiller wrote on Sunday, April 07, 2013:

Hi,

The patch is very straightforward. Basically I:

  1. Unzip the most recent patch into a directory
  2. Go into repo and bring over all the commits from master into rel-411 that will be part of the new patch
    (Note that commits generally come over smoothly but sometime merge work is needed; additionally sometimes there are databases changes which involve migrating the database changes from the sql/4_1_1-to-4_1_2_upgrade.sql to the sql/patch.sql script)
  3. As the last commit in rel-411 I increment the patch number in version.php file
  4. Then use git to generate a list of files that were changed in the new rel-411 commits and then copy these files over to the patch directory.
  5. Then zip up the patch directory and test it (test both when install the patch version directly and when upgrade it from 4.1.1 along with testing the new bug fixes/features in the patch) and then done.

I do like yehsters idea, but, the project currently has a very finite and minimal amount of resources. Something that would be minimal resources to get going would be telling and linking users to install most recent patch in installation setup (and also on first login page to get the users that are using appliance/xampp/ubuntu packages).

For package building during release, the tar/zip/ubuntu packages are automatically built (although the ubuntu maintainer scripts require a couple line of codes to be modified to ensure the upgrade mechanism is working). The xampp package is built in about 2 hours(including testing). The appliance takes about 5 hours because of the large file size and the documentation that goes along with it; although the next version may take much longer since need to upgrade the Ubuntu version.

-brady
OpenEMR

topa1 wrote on Saturday, June 08, 2013:

Whenever I unzip the XAMPP-OpenEMR, the windows starts to come in & out or flicker.

mdsupport wrote on Sunday, June 09, 2013:

Since user downloads (new and upgrades) are served from Sourceforge Files, that is first place users look for patches. If it is impractical to put up all patches there, at least there should be a folder e.g. ‘OpenEMR Patches’ with a single file pointing to patch page on wiki.