Pat K's dashboard

Hi RC -

Good questions.

Elastic Server can be thought of as a "meta packaging" system in that it uses other systems rather than attempting to re-do existing packaging.

In the event of upstream mirror stuff that can be used by apt-get or yum - we let those dependencies kick in. So when we use our admin function to point to a mirror package "foo" then when someone uses "foo" in a bundle - then they get "foo" plus its dependencies.

(In general we have been trying to figure out how to open the upstream mirror pointer functionality in the UI for users besides our admins, as well as let people type in dependencies)

"Bundles" are a form of simple declarative dependency which says "these things should all go together". A good example is rather than having a bundle with just a .WAR file, make a bundle with an appropriate Java, Tomcat and a .WAR. Bundles do not let you specify the order in which those things go in. Which in APT-related things is usually ok - because post-install scripts run after all the installs. In YUM-related things the post-installs run after each individual install, then things can go wrong. In our own usage this has pushed too many things into "run on first boot scripts". This has us thinking about letting you specify an order for the things to install via "loops of loops" if you want.

We have a "can't work together" database which we populate as a result of assembly failures. Things like "Package foo can't work with package bar". We would also like to open this up to other users for their own use.

Our current implementation attempts to bootstrap runtime language artifacts (ruby, java, python, etc) off of the APT and YUM capabilities as a result of the BYO import function basically putting them into a .deb or RPM. This has had mixed results.

The way I deal with Ruby Gems is to import them in a file system tree, then do a post-install script which does a local install. That way I am only getting things that I know I packaged up and I don't have a dependency on an outside mirror which may or may not respond at server assembly time.

Collisions can occur as in your example. Since we can't possibly know all the combinations that can't work - we use our conflict database. So when one user discovers a bad path which won't assemble because of dependency errors we put a rule in the database so the next person who tries those particular packages together gets a message "Foo won't work with Bar, please unselect one of them to proceed with your assembly.

Based on our experiences, and our user's experiences, we are looking at how to put more control in your hands, and to make the system more "URI" based, meaning rather than make you import an upstream package, we should just let you tell us the name, type and location of an artifact and the assembly nodes should then use the native installer for that artifact.

Follow up questions and comments invited. Happy to have a chat as well and hear your ideas in person.

pat k

Hi Nick,

Could you email support (AT) cohesiveft.com with info on the ami id you are launching? We can help you from there via email.

pat k

Hi there,

/var/lib/tomcat6.0

The server.xml file is in /var/lib/tomcat6.0/conf

You will need to "sudo su" and provide your password in order to access that directory.

Changing the tomcat app to use port 80 instead of 8080 should be easy enough.

pk

Hi there,

http://ip_address:2999 is needed just to access the Elastic Server Manager utility application.

The Open Blue Dragon is set up at http://ip_address:8080/openbd/

If you want to move it to: http://ip_adress:8080 - that would be a change to the Tomcat configuration.

If you want it to be http://ip_address
then that might require pinging the Open Blue Dragon folks at their forums. It involves either an internal network redirect from port 80 to 8080 (not super hard if you are comfortable with Linux iptables) or adding an Apache Server to the mix.

Let me know if that covers it.

Cheers,

pat k

Hi there,

Thanks for wanting to try VPN-Cubed. Even though there is no subscription fee other than EC2 costs, we still require you to register for the AMI at this URL:

https://aws-portal.amazon.com/gp/aws/...

Thanks,

Pat K

Hi,

Thanks for those suggestions. Sorry it took a little longer than I thought.

We have put in a fix into all Elastic Server new assemblies going forward (from about 10 minutes ago) which essentially puts in the missing tty nodes on EC2 when needed.

We implemented this as an Elastic Server "run on boot script" component which goes into all builds. If for some reason you don't want this script it is /etc/cft.d/onboot/tty-tweak-for-ec2

On the next release of our factory nodes for EC2 we will put in a more specific fix for EC2 only, and then remove the run-on-boot-script from all future assemblies.

Thanks for the patience.

Pat K
CohesiveFT

Hmm...

Thanks for the report - we will look into it.

HI Bennett,

Sorry about the problems. We did have an issue with one of our front end services this weekend.

Overall our service is reliable. We do have occasional down time - but it is mostly planned and you are notified of the time window in advance via the site it self.

We update the service weekly with new capabilities With that type of release cycle there are some bumps - but we do our best to keep new stuff coming combined with disruptions at a minimum.

Cheers,

Pat K
CTO, CohesiveFT

No - the free edition is currently an EC2-only offering. The uniformity and volume of EC2 means a lot of people get a lot of value out of the free edition - with very little need for support from us.

We can work with customers to provision VPN-Cubed paid edition Managers in their Rackspace/Mosso account.

Ok - now I think I understand. More answers to follow...

pk

Sorry. I must have understood you. I thought you wanted a "stock" Ubuntu server with no customization's done via Elastic Server.

"All the flexibility is great but I just need a quick Ubuntu 9.04, stock server. What's the quickest way to get that?"

If I share out a VM with you - you can download it - and do whatever customization you want by hand. Which is what I thought you wanted. If you want to be able to simply add any of the community components, or privately uploaded components to a Jaunty, then we can't meet your need until we publicly release Jaunty support.

The reason for the "bill of materials" approach of Elastic Server is that you can capture the instructions for a server of your design and then be able to rapidly re-deploy it to different Virtual Machine or Cloud Formats (VMware, Xen, Parallels, KVM, VIrtual Iron, EC2, Open Source Eucalyptus, ElasticHosts, etc) with a click of a button.

Elastic Server allows you to capture YOUR server design and share with others (who can then make an instance in any of the above formats, and often in their OS of choice) without having to know the pages of commands to build such a server themselves.

For examples see the Open Blue Dragon server or the Razuna server.
http://elasticserver.com/site/razuna
http://elasticserver.com/site/open-bl...

These Open Source teams deliver finished servers which their users can customize by adding software components, choosing their VM type or cloud. Lots of time saved by all.

Similar situations exist in the world of Appliance Vendors, Traditional ISVs and Enterprises.

We will post here when we turn on Jaunty for Community and Personal Edition accounts.

Cheers,

pk

Given all of the software components out there it is unlikely that any team, regardless of size, could keep them all up to date. Elastic Server allows you to import pretty much any software you want. You can then choose to keep it private or publish it to the community.

Here is an example of how to do that: http://www.cohesiveft.com/dnld/Elasti...

There is lots of software in ES you can't see - imported and used by people and teams to use for their projects.

We welcome contributions and updates from community members.

Cheers - pat k

PS. Regarding your previous question it it likely to be a couple weeks before we have Jaunty available to all the accounts. If you want a stock Jaunty in a particular VM format - let me know and I will make one and share it out to you. It will show up on your "Servers" page.

Whoops - what VM format?

Soon means we are testing and setting up the necessary mirror infra.

In the short run - sign up for the free edition - email me your elastic server user ID at pjkerpan (at) cohesiveft.com - and I will use our collaboration features to share out a Jaunty server to you for download.

Jaunty coming soon - then you just click on "Ready to Build" and pick the OS only.

Public vs. Private vs. funky aws DNS names.

Sorry for the confusion. We will try to make the documentation more clear.

Yes - the way your read the long amazon DNS name to parse out the public IP address is correct. This is different that Elastic IP.

VPN-Cubed does not require Elastic IP unless you WANT to make one of the managers well known at a consistent address for some reason.

WITH MANAGERS IN THE SAME EC2 REGION (US or EU):

Use the internal, private IP addresses of the VPN-CUbed Managers; both for "peering" the same region managers and for any overlay network devices you are connecting to the managers.

IF you use the PUBLIC addresses you will be charged for network traffic between them.

WHEN USING MANAGERS IN DIFFERENT EC2 REGIONS (US and EU)

In order for these devices to communicate you will have to use the PUBLIC IP addresses of the Managers to "peer" them. You will be charged for network traffic between them.

When connecting overlay network devices in one region to a manager in another region (DEFINITELY NOT RECOMMENDED!!!!) you would need to use the PUBLIC IP address of the Manager in Region A, in the config file of a device in Region B.

Because Amazon Security groups cannot be shared across regions, nor referenced - each region will have their own security groups for the managers; you will need to provide permission in each managers respective security group for access to/from the other managers.

The keys to remember are when to use the public IP versus the internal private IP of the Managers in the peering process and security group configuration.

When the Public IP address is to be used, you can use either its simple address as you parsed out of the AWS DNS name, or the AWS DNS name can be used. In this case they are interchangeable. We will change the document to reflect this. That said - for visual simplicity we normally use the "parsed out" name, rather than the long name.

Accessing the ADMIN screen: requires access to port 8000 in your EC2 security group for the address you are connecting from.

In the instructions it tells you to authorize port 8000 access in your security group for the IP address or network you will be doing the administration from via this command:

ec2auth vpncubed-mgr –P tcp 8000 –s IP_WHERE_YOU_WILL_MANAGE_FROM/32

This can also be done via ElasticFox plugin or the AWS Console.

The IP address here is the public facing address you will connect from. So if you are at home on a Comcast cable modem this would be the address currently assigned to you by comcast 69.x.x.x something possibly. The "/32" is an artifact of the API not masking your need to know that /32 means "just this address".

If you don't set this up you will not be able to access admin screen.

Quick answer on the activation key - it is an artifact of AWS Devpay. It is not used anywhere.

More to follow on the configuration question.

Hi Brian,

Ping me at pjkerpan (at) cohesiveft.com and happy to chat on this topic.

Pk

Thanks for the further detail.

We will look at Python 2.5 in the foundation.

Native code in the virtualized world especially in places like EC2 is an interesting issues. I will follow up with thoughts on that.

Re: things in the upstream mirrors - we agree - in those cases we need to look a bit more like a search engine. But...for all the packages in the mirrors - there are way more not in the mirrors. Most commercial code isn't and won't be. No proprietary customer code is. And the lions share of the world of ruby, erlang, java, mono/.net, etc are not. So giving the inventors of those applications and stacks a place to stick things that can be distro-neutral and vm/cloud-neutral is part of the give back on the other side of the problem.

Improved documentation of our CFT-imported packages is a good suggestion. Thanks for the prod.