I've gotten pretty far into a deployment of my Meteor application on Distelli. Like, almost there. I've done everything as far as setting up the EC2 box, creating a user group [which didn't even seem necessary as I was able to SSH into the box with full rights without specifying my machine's IP], creating an elastic IP, successful build, and deployment to that box. But, I can't seem to check if Meteor is actually running (note: when I ssh in, there are active instances of Mongo and Node, so SOMETHING is running).
The problem has something to do with associating the elastic IP with my ROOT_URL and domain. I'm just not sure what to do at this step and can't seem to find any directions that are Meteor specific. Been using these guides:
https://www.distelli.com/docs/tutorials/how-to-set-up-aws-ec2
https://www.distelli.com/docs/tutorials/deploying-meteor-applications
http://gregblogs.com/tlt-associate-a-namecheap-domain-with-an-amazon-ec2-instance/
Recap: Distelli deployment is a success, but I get the follow error just before finishing:
Error: $ROOT_URL, if specified, must be an URL
I've set my ROOT_URL to my domain, and associated according to the previous guide. I can run traceroute on the IP, but like port 3000, so my inclination is the Meteor build is silently failing.
My manifest: https://gist.github.com/newswim/c642bd9a1cf136da73c3
I've noticed that when I point the CNAME record to my ec2 public DNS, NameCheap (aptly named) adds a . to the end of the record. Beyond that, I'm pretty much stumped.
Related
My application is behind a corporate firewall and proxy. I am able to add new packages but somehow I cannot update the catalog. Probably because websockets are not allowed through the firewall.
Is there a method to manually get the latest catalog? The proxy variables HTTPS_PROXY and HTTP_PROXY are set of course.
Opening db file /pkgs/meteor/.meteor/package-metadata/v2.0.1/packages.data.db
In remote catalog refresh
lastSync = { timestamp: 1509131556799, _id: 'lastsync' }
Unable to update package catalog (are you offline?)
If you are using Meteor behind a proxy, set HTTP_PROXY and HTTPS_PROXY environment variables or see this page for more details:
https://github.com/meteor/meteor/wiki/Using-Meteor-behind-a-proxy
Error during WebSocket handshake: Unexpected response code: 400
You could update the catalog on your dev machine, then build it and deploy with the updated packages as a tar.gz in the restricted environment.
Otherwise just remove all packages and then add them back in if that downalods the latest version of all the packages.
The "solution" was
Meteor refresh on my laptop with normal internet connection
Copy the content .meteor/package-metadata/ to the internal system
Run Meteor update with METEOR_OFFLINE_CATALOG=1
Quite an annoying process. I think a meteor refresh should be done without Websockets or at least have the choice of disabling. DISABLE_WEBSOCKETS=1 did not work in my case.
I have recently created a very small Google Compute Engine instance, naively thinking it's one of those easily scalable things Google people keep raving about.
I used the quick deployment feature of Wordpress and it all installed itself nicely, so I started configuring and adding data etc.
However, I then found out that I can't scale an existing instance (i.e. it won't allow me to change the instance type to a bigger one. I don't get why not, but there you go.), so it looks like I need to find a way to migrate my Wordpress installation to a new instance.
Will I simply be able to create a new instance and point it at the persistent disk my small instance currently uses, et voila, Bob's your uncle?
Or do I need to manually get the files and MySql data off the first instance and re-import into an empty new instance?
What's the easiest way?
Any advise or helpful links would be appreciated.
Thanks.
P.S.: Btw, should I try to use the Google Cloud SQL store instead of a local MySql installation?
In order to upgrade your VM:
access the VM's settings in the Developers Console (your project -> Compute -> Compute Engine -> VM instances -> click on the VM's name)
Scroll down to the "Disks" section, and un-check "Delete boot disk when instance is deleted"
Delete the VM in question. Take note that the disk, named after the instance, will remain.
Create a new VM, selecting "Existing disk" under Boot disk - Boot source. In the next box down, select the disk from point 3 above, as well as a bigger machine type.
The resulting new instance will use the existing disk from the old one, with improved hardware / performance.
As for using Cloud SQL in lieu of a VM-installed database, it's perfectly feasible, and allows to adjust the Cloud SQL instance to match your actual use. A few consideration when setting up this kind of instance:
limit the IPs allowed to connect to your Cloud SQL instance to your frontend's IP, and perhaps the workstation's IP or subnet from which you maintain the database out of.
configure Cloud SQL to use SSL certificates.
Sammy's answer covers the important stuff I just wanted to clarify how your files are arranged on the two disks that are attached to your instance:
The data disk contains /var/www/ which is all of the wordpress files. It's mounted on the instance at /wordpress
The boot disk contains everything else, including the MySQL database that was created for the Wordpress installation.
I'm running a .net server on Amazon's Elastic Beanstalk and when I try to instantiate AmazonDynamoDBClient it fails. According to the information I've been following from these two pages:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.iam.roles.apps.html
http://docs.aws.amazon.com/AWSSdkDocsNET/latest/DeveloperGuide/net-dg-roles.html
It should retrieve the credentials from the IAM role assigned to the EC2 instance.
It has the DynamoDBFullAccess template as a policy.
If I supply the credentials in the code itself through the web.config file it works, but only when debugging locally and not when deployed to elastic beanstalk.
Here is the code that breaks it:
AmazonDynamoDBClient client = new AmazonDynamoDBClient();
or
AmazonDynamoDBClient client = new AmazonDynamoDBClient(new InstanceProfileAWSCredentials());
Neither works. And I can't seem to retrieve crash logs from elastic beanstalk, so it is hard to debug. I'm pretty sure that I'm following the descriptions in those two links to the letter and am confused.
I've been trying to solve this for the better part of a day and would really appreciate some help. If there is any information missing, please let me know.
Thank you.
If you go to aws console and select ec2 view instances you will see the ec2 instance for your elastic beanstalk. The name of that instance will be either "Default-Environment" or whatever name you chose for your elastic beanstalk environment. Then you can ssh to that ec2 instance and view logs. For example my tomcat logs are stored at /var/log/tomcat7
You can also scp your credential file to your ec2 host just for debug and run the app. It should work because you already have it working on your local machine. but I guess this approach is not recommended and may has security concern.
This should at least get you started. may be an EC2 expert can help you solve the real problem :)
On a RedHat 6 server, a third party application requires to be root to run and needs access to sqlplus. I have a running database, I can run sqlplus as user 'oracle'. When logged in as user root, 'sqlplus usr/pwd#dbname' works as expected. The trouble is that this agent needs to run sqlplus with no parameters and it always returns ORA-12546: TNS:permission denied.
I've read a dozen times that enabling root to launch Oracle is a security issue but I really have no other choice.
Running Oracle 11.2.0.1.0.
Any help will be much appreciated as I've googled for 2 days with no success.
From the documentation, ORA_12546 is:
ORA-12546: TNS:permission denied
Cause: User has insufficient privileges to perform the requested operation.
Action: Acquire necessary privileges and try again.
Which isn't entirely helpful, but various forum and blog posts (way too many to link to, Googling for the error shows a lot of similar advice) mention permissions on a particular part of the installation, $ORACLE_HOME/bin/oracle, which is a crucial and central part of most of the services.
Normally the permissions on that file would be -rws-r-s--x, with the file owned by oracle:dba, and this error can occur when the word-writable flag - the final x in that pattern - is not set. Anyone in the dba group will still be able to execute it, but those outside will not.
Your listener seems to be fine as you can connect remotely, by specifying #dbname in the connect string. The listener runs as oracle (usually, could be grid with HA, RAC or ASM) so it is in the dba group and can happily hand-off connections to an instance of the oracle executable.
When you connect without going via the listener, you have to be able to execute that file yourself. It appears that root cannot execute it (or possibly some other file, but this is usually the culprit, apparently), which implies the world-writable bit is indeed not set.
As far as I can see you have three options:
set the world-writable bit, with chmod o+x $ORACLE_HOME/bin/oracle; but that opens up the permissions for everyone, and presumably they've been restricted for a reason;
add root to the dba group, via usermod or in the /etc/group; which potentially weakens security as well;
use SQL*Net even when you don't specify #dbname in the connect string, by adding export TWO_TASK=dbname to the root environment.
You said you don't have this problem on another server, and that the file permissions are the same; in which case root might be in the dba group on that box. But I think the third option seems the simplest and safest. There is a fourth option I suppose, to install a separate instant client, but you'd have to set TWO_TASK anyway and go over SQL*Net, and you've already ruled that out.
I won't dwell on whether it's a good idea to run sqlplus (or indeed the application that needs it) as root, but will just mention that you'd could potentially have a script or function called sqlplus that switches to a less privileged account via su to run the real executable, and that might be transparent to the application. Unless you switch to the oracle account though, which is also not a good idea, you'd have the same permission issue and options.
Question to all the JabbR/SignalR/AppHarbor/Janrain/ASP.NET integration experts out there:
I successfully forked JabbR from GitHub and cloned into my repo!!!
I also successfully deployed to a new AppHarbor application in the Beta environment in order to enjoy WebSocket support!!!
I also successfully set up JanRain's engage service for authentication for my application.
I also happily saw my application start up on the public domain (http://jabbr-14.apphb.com/) and successfully created my first account and got authenticated.
NOW, I just CAN't post, create, broadcast, etc., or —for that matter— do anything useful in my chat!!!
How do I start using this thing?!?!
Basically this is how my app looks in the browser, but I just can't get it to do anything!!!
As #halter73 mentioned, it was only that commands have to preceded with '/'.