I bundled my application and put it onto my server. I am running the app via upstart:
exec sudo -u myuser PORT=3005 MONGO_URL=mongodb://localhost:27017/ms ROOT_URL=http://www.example.com/ /usr/bin/node /var/www/priv/example.com/bundle/main.js >> $
The important part (i think) is:
exec sudo -u myuser
When i curl my app via:
curl http://www.example.com/?_escaped_fragment_=
I get an empty body. My log file says:
spiderable: phantomjs failed: { [Error: Command failed: /bin/bash: /root/.bashrc: Permission denied
Can't open '/dev/stdin'
] killed: false, code: 255, signal: null }
stderr: /bin/bash: /root/.bashrc: Permission denied
Can't open '/dev/stdin'
I did chmod 777 on /root/.bashrc but without any success. If i do /bin/bash /root/.bashrc as 'myuser' i also get permission denied.
Could any one tell me how to set the permissions so that phantomjs can do what it has to do? Can i specify that ~/.bashrc is used anywhere? I would really love to see my stuff on google :-)
Thanks alot!
Manuel
Updates:
I have phantom.js 1.8.2 installed via npm.
Running the application as root does not help. Error then is:
spiderable: phantomjs failed: { [Error: Command failed: Can't open '/dev/stdin' ] killed: false, code: 255, signal: null } stderr: Can't open '/dev/stdin'
I found out, that it seems to be a package that causes the problem. I opened an issu here:
github.com/alanning/meteor-roles/issues/3
Alanning fixed the problem but spiderable still did not work. The solution was to remove phantomjs because i installed it via npm. I then reinstalled it from http://phantomjs.org/download.html directly. Now it is working!
I found that problem again, the problem were publications on the server-side that in some cases just returned but did not stop the subscription.
e.g. on server i have a publication with
return unless #userId
The correct way would be:
return this.stop() unless #userId
If a crawler comes, it will never be authenticated, so be careful to end publications correctly.
Related
I have trouble pulling a docker image from Rstudio using babelwhale libary. I tried running the command below
babelwhale::pull_container("ubuntu:18.04")
But it gave the following error
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.40/images/create?fromImage=ubuntu&tag=18.04: dial unix /var/run/docker.sock: connect: permission denied
Error in processx::run("docker", c("pull", container_id), echo = TRUE) :
System command error
It seems like you are using RStudio in a unix system which probably requires root access to pull an image from docker. I think you should try launching Rstudio with sudo privilege from the terminal using the command
sudo rstudio
and then rerun the babelwhale function above.
I am using lftp mirror -R to sync a local dir to a remote sftp dir
Just to get myself super clarified, the script my i am running lftp -f is
as follows
open sftp://hostname port
user username password
mirror -R local_dir sftp_dir
exit
However I keep getting exit code 1 from mirror -R,even though from the standard stdout it seem that it has successfully uploaded the file and I can verify that the files are indeed upload from sftp.
So just wondering why is that happening and how i can get correct exit code
Non-zero exit code without error messages means that something has silently failed. Most often it is "chmod" operation. Try adding --no-perms option. To be sure, enable debug and see the interaction with the server.
I couldn't find existing posts related to my issue. On a Digital Ocean Droplet, mup setup went fine, but when I try to deploy, I get the following error. Any ideas? Thanks!
root#ts:~/ts-deploy# mup deploy
Meteor Up: Production Quality Meteor Deployments
Building Started: /root/TS/
Bundling Error: code=137, error:
-------------------STDOUT-------------------
Figuring out the best package versions to use. This may take a moment.
-------------------STDERR-------------------
bash: line 1: 31217 Killed meteor build --directory /tmp/dc37af3e-eca0-4a19-bf1a-d6d38bb8f517
Below are the logs. node -v indicates I am using 0.10.31. How do I check which script is exiting with the error? Any other ideas? Thanks!
error: Forever detected script exited with code: 1
error: Script restart attempt #106
Meteor requires Node v0.10.29 or later.
error: Forever detected script exited with code: 1
error: Script restart attempt #107
Meteor requires Node v0.10.29 or later.
error: Forever detected script exited with code: 1
error: Script restart attempt #108
stepping down to gid: meteoruser
stepping down to uid: meteoruser
After I went back to an old backup of the DO Droplet, and re-ran mup setup and mup deploy, I now get this in the command line output
Building Started: /root/TS
Bundling Error: code=134, error:
-------------------STDOUT-------------------
Figuring out the best package versions to use. This may take a moment.
-------------------STDERR-------------------
FATAL ERROR: JS Allocation failed - process out of memory
bash: line 1: 1724 Aborted (core dumped) meteor build --directory /tmp/bfdbcb45-9c61-435f-9875-3fb304358996
and this in the logs:
>> stepping down to gid: meteoruser
>> stepping down to uid: meteoruser
Exception while invoking method 'login' TypeError: Cannot read property '0' of undefined
at ServiceConfiguration.configurations.remove.service (app/server/accounts.js:7:26)
at Object.Accounts.insertUserDoc (packages/accounts-base/accounts_server.js:1024)
at Object.Accounts.updateOrCreateUserFromExternalService (packages/accounts-base/accounts_server.js:1189)
at Package (packages/accounts-oauth/oauth_server.js:45)
at packages/accounts-base/accounts_server.js:383
at tryLoginMethod (packages/accounts-base/accounts_server.js:186)
at runLoginHandlers (packages/accounts-base/accounts_server.js:380)
at Meteor.methods.login (packages/accounts-base/accounts_server.js:434)
at maybeAuditArgumentChecks (packages/ddp/livedata_server.js:1594)
at packages/ddp/livedata_server.js:648
Exception while invoking method 'login' TypeError: Cannot read property '0' of undefined
at ServiceConfiguration.configurations.remove.service (app/server/accounts.js:7:26)
at Object.Accounts.insertUserDoc (packages/accounts-base/accounts_server.js:1024)
at Object.Accounts.updateOrCreateUserFromExternalService (packages/accounts-base/accounts_server.js:1189)
at Package (packages/accounts-oauth/oauth_server.js:45)
at packages/accounts-base/accounts_server.js:383
at tryLoginMethod (packages/accounts-base/accounts_server.js:186)
at runLoginHandlers (packages/accounts-base/accounts_server.js:380)
at Meteor.methods.login (packages/accounts-base/accounts_server.js:434)
at maybeAuditArgumentChecks (packages/ddp/livedata_server.js:1594)
at packages/ddp/livedata_server.js:648
The memory issue stems from using DigitalOcean's $5 Droplet. To solve the problem, I added swap to the server, as explained in detail below.
Create and enable the swap file using the dd command :
sudo dd if=/dev/zero of=/swapfile bs=1024 count=256k
“of=/swapfile” designates the file’s name. In this case the name is swapfile.
Next prepare the swap file by creating a linux swap area:
sudo mkswap /swapfile
The results display:
Setting up swapspace version 1, size = 262140 KiB
no label, UUID=103c4545-5fc5-47f3-a8b3-dfbdb64fd7eb
Finish up by activating the swap file:
sudo swapon /swapfile
You will then be able to see the new swap file when you view the swap summary.
swapon -s
Filename Type Size Used Priority
/swapfile file 262140 0 -1
This file will last on the virtual private server until the machine reboots. You can ensure that the swap is permanent by adding it to the fstab file.
Open up the file:
sudo nano /etc/fstab
Paste in the following line:
/swapfile none swap sw 0 0
Swappiness in the file should be set to 10. Skipping this step may cause both poor performance, whereas setting it to 10 will cause swap to act as an emergency buffer, preventing out-of-memory crashes.
You can do this with the following commands:
echo 10 | sudo tee /proc/sys/vm/swappiness
echo vm.swappiness = 10 | sudo tee -a /etc/sysctl.conf
To prevent the file from being world-readable, you should set up the correct permissions on the swap file:
sudo chown root:root /swapfile
sudo chmod 0600 /swapfile
This only worked for me by increasing the swap space to 1gb:
Make all swap off
sudo swapoff -a
Resize the swapfile
sudo dd if=/dev/zero of=/swapfile bs=1M count=1024
Make swapfile usable
sudo mkswap /swapfile
Make swapon again
sudo swapon /swapfile
I have been able to get past #mup setup. I get the following error;
Meteor Up: Production Quality Meteor Deployments
------------------------------------------------
Started TaskList: Setup (linux)
[212.1.213.20] - Installing Node.js
[212.1.213.20] â Installing Node.js: FAILED
-----------------------------------STDERR-----------------------------------
Warning: Permanently added '212.1.213.20' (RSA) to the list of known hosts.
stdin: is not a tty
sudo: sorry, you must have a tty to run sudo
sudo: sorry, you must have a tty to run sudo
sudo: sorry, you must have a tty to run sudo
sudo: sorry, you must have a tty to run sudo
-----------------------------------STDOUT-----------------------------------
----------------------------------------------------------------------------
Completed TaskList: Setup (linux)
I've found a lot about the error stdin: is not a tty but none of them make much sense to me.
Open your /etc/sudoers file, find the line that says Defaults requiretty, and change it to Defaults !requiretty.
This will disable the tty requirement globally.
I'm trying to deploy from apigee tool with the following command:
apigeetool deployproxy -n my_proxy_name -o myorgname -e test -d apiproxy-3/ -b my_base_path -u myusername -p mypassword
and getting always this:
Import failed to /v1/organizations/myorg/apis?action=import&name=my_proxy_name with status 400:
{
"code" : "messaging.config.beans.InvalidBundle",
"message" : "Bundle is invalid. Unable to read/find APIProxy contents",
"contexts" : [ ]
}
At first I thought it was my proxy development.. so I tried downloading the proxy as zip file, uncompressing it, and then uploading from this command without any changes, and got the same thing.
Could this be a problem with me being on yosemite dev build 2?
the issue here is with the paid hosted option, it seems My org was having an isse and support is looking into it.
Try renaming the subdirectory from apiproxy-3 to apiproxy, then retry.