Amazon Linux rather than Ubuntu?
We are planning to move the system in Hong Kong to an Amazon EC2/RDS implementation. The local Amazon support partner that we would like to use has suggested that instead of going with a Unbuntu 14.4 instance we should use an Amazon Linux AMI. [This is apparently based on the Centos distribution which is itself an RHEL build.]
Should we stick with Ubuntu 14.4 or see Amazon Linux works?
[I am trying to move towards giving up system responsibility for the system in Hong Kong and hence an AMI that the Hong Kong support partner is happy with makes sense.]
Regards, Tim G
Re: Amazon Linux rather than Ubuntu?
People are either yum or deb based....I have always used Ubuntu or a variant of Debian, I have never gone to the darkside and used Redhat or Fedora....
In theory it shouldnt make any difference...bar that you might find little wierd differences that you will have to wing..things like print drivers and fonts might differ
Aside from that everything else is GA for both
Re: Amazon Linux rather than Ubuntu?
The reality is the only question that should be asked is
Which one is the best for you and the software.....because if the only reason they want you to use AL is that thats what they know...is not really the best reason...
That being said if they are providing system's administration you want to make sure they know the OS.
Re: Amazon Linux rather than Ubuntu?
Ben - thanks for this. The print side will be all new to me since we are coming from a Win 2012 Server environment. I will try the Amazon Linux AMI and see how I go. As I said, I would really like to exit the OS support role - both the practice manager and I are starting to get concerned about the risks of having a 70 year old bloke look after the system.
Regards, Tim G
Re: Amazon Linux rather than Ubuntu?
Once setup the majority of the work is done - the most technical part of the setup by far is the VPN configuration - redundancy and then print setup.
I dont think it matters as long as it works...with printing my advice is use some sort of inbuilt generic service to test printing before you do OpenVPMS.
So configure VPN
COnfigure printers
then do Open
Also with mobile services the other option is to setup SSL and Https and use secure password logins.
OpenVPMS's inbuilt security sortta sucks so you cant use it with out SSL on an open connection. and if you do - you are going to have to proactively enforce passwords that are really highgrade...
The Application is VERY VERY vulnerable to brute force attacks
But that gets round configuring roadwarrior type vpns.
The only real reason for most VPN solutions is printing. Google Cloud Print just is not mature enough to utilize.
Re: Amazon Linux rather than Ubuntu?
Let me know how you go - I have always wondered if the AMAZON linux version was any good.
Re: Amazon Linux rather than Ubuntu?
Wilco - the schedule is for the move to Amazon to take place at Christmas when we are in Hong Kong, so should have some data as soon as I catch up on 7 weeks away.
Regards, tim G
Re: Amazon Linux rather than Ubuntu?
I was cleaning up old things and came across this post, so I though I should update things.
In fact I switched back to Ubuntu 14.4 for two reasons:
a) the Amazon support partner in Hong Kong had little more knowledge of Amazon Linux that I did;
b) there is far far far more on the web for Unbuntu than Amazon Linux
If anyone who reads this is contemplating a switch to Amazon and is (like me) not a linux guru, yell - I have a long cheat sheet for running up OpenVPMS under Ubuntu 14.4
Regards, Tim G
Re: Amazon Linux rather than Ubuntu?
Hi Tim,
would love to see your cheat sheet. I've got a server up and running but am about to blow it away and upgrade to a 1.9 implementation. Would love to see where you got too.
Peter Nunn
pnunn[at]intq[dot]it
Re: Amazon Linux rather than Ubuntu?
Peter - will send what I currently have to your email address. NOTE - this is currently a mess since it is a text cheat sheet I built on the fly as I was doing things.
Note also that although I intended to run the database in an RDS instance, we ran into performance problems associated with the complex schedule and worklist view expressions that we use. This led to OVPMS-1879 which will be part of 1.9.2 - however, even with this running the database in RDS felt slower than running it in the EC2 instance.
Hence we are now running two EC2 instances (m3.xlarge), one for production and the other as standby with one in the A region and the second in the B region. Standby runs a slave copy of the database, and the samba file store gets rsync'ed from production every hour. The database (and root) run in a 100GB io1 volume set to provide 4000 IOPS, the samba file store runs in a 100GB gp2 volume. The 4000 IOPS is overkill for normal use, but I needed it to minimise the cut-over time from the in-house system to Amazon (our sql dump file is around 17GB and during the restore the io1 volume was running up to 3700 writes/sec.
What I do not have running yet is the automatic switch from standby to production status.
Cutover was last Wednesday morning and I am down to 3 other problems:
1) can't get client authentication working on an android or iphone so one vet who wants the check things from his iPhone currently cannot;
2) External Edit does not work with client authentication;
3) the two big FujiXerox printers have no linux support so staff must use print preview/print to print to them
One final hooker which caught us on 'Amazon Day 1': if you clone a new instance from the snapshot of an existing instance, the locale and language get reset to the US - so the first invoices were printing in US format.
I should also say something about VPNs. Initially I thought that everything was going to run up the VPN between the office(s) and Amazon. However, we ended up using the VPN only to allow OpenVPMS to talk to the printers. Access to the samba file store is via the (public) elastic IP address, as is the OpenVPMS access. OpenVPMS access is controlled by turning on HTTPS and client authentication in Tomcat, and samba access is controlled via the Amazon security group which is set to allow access only from the three office IP addresses for the ports used by samba.
Using the elastic IP addresses means that switching production from the A to the B system needs no change in any of the workstations because we will re-associate the production elastic IP address from the A to the B system.
Regards, Tim G