I'm stuck at the mup setup. Trying to set it up on my Dreamhost server.
Here is what I started with after running mup setup:
Meteor Up: Production Quality Meteor Deployments
------------------------------------------------
Started TaskList: Setup (linux)
[mydomain.com] - Installing Node.js
[mydomain.com] ✘ Installing Node.js: FAILED
-----------------------------------STDERR------------
tty present and no askpass program specified
Sorry, try again.
sudo: no tty present and no askpass program specified
Sorry, try again.
Then I installed node manually on my server, and set the mup file to "setupNode": false. Tried again and got that:
Meteor Up: Production Quality Meteor Deployments
------------------------------------------------
Started TaskList: Setup (linux)
[mydomain.com] - Installing PhantomJS
[mydomain.com] ✘ Installing PhantomJS: FAILED
-----------------------------------STDERR-----------------
tty present and no askpass program specified
Sorry, try again.
sudo: no tty present and no askpass program specified
Sorry, try again.
Finally, I also deactivated the PhantomJS install, tried again to run mup setup and got that:
Meteor Up: Production Quality Meteor Deployments
------------------------------------------------
Started TaskList: Setup (linux)
[mydomain.com] - Setting up Environment
[mydomain.com] ✔ Setting up Environment: SUCCESS
[mudomain.com] - Copying MongoDB configuration
[mydomain.com] ✘ Copying MongoDB configuration: FAILED
-----------------------------------STDERR-----------------
Warning: Permanently added 'mydomain.com,69.163.152.69' (RSA) to the list of known hosts.
scp: /etc/mongodb.conf: Permission denied
Killed by signal 1.
-----------------------------------STDOUT-----------------
----------------------------------------------------------
Completed TaskList: Setup (linux)
I am not sure what to do or try next. Thanks in advance for your help and suggestions.
Its seems like its a Permission problem.
Try with sudo mup setup or whatever name process are you running, initialize with the sudo keyword
From dream Host forums (admin or tutor post).
node.js — which is used by Meteor — causes some weird issues on our shared hosting servers that can trigger this behavior. We're aware of
the issue, but, for various reasons, it's been difficult to fix.
That being said, Meteor won't work on a shared hosting account anyway,
as it runs as a persistent server process, which isn't permitted.
You'd need a DreamHost VPS or dedicated server to run Meteor.
So if you don't have a dreamHost VPS or dedicated server, and you only want to deploy the app give a try to Modulus.io, it works pretty fine with meteor, or use the meteor deploy servers, doc here
This happens because Sudo isn't installed on the target machine.
On my Debian target machine I did apt-get install sudo to resolve this.
For a RedHat flavor (Centos etc) target machine you might do yum install sudo etc.
However mup is supported for Ubuntu only so it's very likely to run into issues with other flavors. You might want to stick with Ubuntu target machines to avoid headaches like these.
Related
I'm running Vagrant version 2.2.19 with VirtualBox version 6.1 on Mac OS Monterey version 12.3.1.
When running vagrant up or vagrant up --provision, I'm receiving the following error:
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.
Upon checking the logs, in provisioner-utility-source-core.log I can see the following log:
[0;38;5;2m ▷ Running the [0m[1m[0;38;5;5m'utility-source-core'[21m[0;38;5;2m provisioner...[0m[0m[0m
[0m[39m[2m* Updating the "core" utility on the "master" branch...[21m[0m
fatal: unsafe repository ('/srv/provision/utilities/core' is owned by someone else)
To add an exception for this directory, call:
git config --global --add safe.directory /srv/provision/utilities/core
[0;38;5;9m ! The [0m[1m[0;38;5;5m'utility-source-core'[21m[0;38;5;9m provisioner ran into problems, the full log is available at [0m[1m[0;38;5;5m'/var/log/provisioners/2022.04.18_18-32-31/provisioner-utility-source-core.log'[21m[0;38;5;9m. It completed in [0m[1m[0;38;5;5m0[21m[0;38;5;9m seconds.[0m[0m
In the above, can see a fatal error:
unsafe repository ('/srv/provision/utilities/core' is owned by someone else)
However, I cannot see any resources online to solve the above fatal error.
What I've tried:
Running vagrant halt then vagrant destroy and then vagrant up to create the box again, and then running vagrant up to see if it solves things (get the same error)
Added Git SSH (using this guide) in case it was a Git error
Uninstalled and then reinstalled VirtualBox
Cleared out IPs from /etc/hosts/hosts, and then ran vagrant up again, to see if there were any conflicts.
Have tried running git config --global --add safe.directory /srv/provision/utilities/core, then re-ran vagrant up --provision - but it does nothing.
Note: I have allowed oracle permissions via security and privacy and have rebooted my machine so it's in effect.
Is there any way to get VVV running again?
This is a known issue that was fixed in newer versions of VVV. Update to at least VVV 3.10.1 and re-provision.
If it is still happening despite updating to newer VVV, raise a GitHub issue.
I'm the VVV project lead, usually when we see these issues we fix them, this isn't something you should need to fix yourself. But if you use stackoverflow to report bugs we don't see it. Either raise a GitHub issue or ask in the VVV slack.
https://github.com/Varying-Vagrant-Vagrants/VVV/issues/new/choose
I have an application that builds in 5 minutes on the Mac. When I try to build in Docker or directly in Ubuntu, the machine completely hangs at some point. It so bad that I can't even ssh into the machine. It eventually times out. I am using Meteor 1.4.2.3, Ubuntu 16.04 and Docker 16.04 with Meteor installed.
I thought maybe it was related to tar and 7z, so I upgraded tar and 7z. Still hangs. It hangs when I building on web.browser. There is high I/O waits and a bunch of blocked processes according to vmstat.
This is the command I'm running:
meteor build --allow-superuser --server-only --directory /tmp/build
Is their any way to get more info about what's going wrong? I also tried to
meteor remove ecmascript --allow-superuser
b/c one article said this may be an issue. Hangs.
I am trying to get my localhost working on my remote (mediatemple) server.
I have bundled it up and have a /myurl.com/bundle folder with the following files.
this folder contains
main.js
npm-debug.log
programs
server
How do I get this to run?
You should take a look in the README inside the bundle folder. Normally everything ist described there to start your app.
Make sure that NODEJS and MONGO is installed on your remote server. This is NOT included in your bundle as well as NODEJS is not present.
If you are running a system like debian or ubuntu normally you can do the installation with
apt-get install nodejs mongo
Make sure, that the nodejs has release v0.10.36 or v0.10.38
node --version
At the README you see the necessary ENV-VARS like MONGO_URL and PORT you need to set to start your meteor app.
If you have running a apache server already the PORT 80 is already blocked, so try PORT=3000 to start your meteor app.
Example:
MONGO_URL='mongodb://localhost:27017/yourapp' ROOT_URL="http://yourhost" PORT=3000 node main.js
If using as above you do not need to export the ENV-VARS before start
Sometime when starting, there are missing NPM – you get fiber errors
In that case
cd programs/server
npm install
and the try start again.
Good luck
Tom
(I'm writing this response assuming that you are not worried about scalability issue, respond in comment if you want to scale your app)
The best option for running a node application, which Meteor application is, is by using forever.
npm install forever
forever start simple-server.js
If you want to figure out how to see the log files and how to stop/restart your service, you can run forever --help to see all the commands.
I have just deployed my first production Meteor app, but ran into a pretty significant issue. When I tried to run my app, I get the following error:
/home/hiapp/bundle/programs/server/node_modules/fibers/future.js:173
throw(ex);
^
Error: /home/hiapp/bundle/programs/server/npm/npm-bcrypt/node_modules/bcrypt/build/Release/bcrypt_lib.node: invalid ELF header
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at bindings (/home/hiapp/bundle/programs/server/npm/npm-bcrypt/node_modules/bcrypt/node_modules/bindings/bindings.js:74:15)
at Object.<anonymous> (/home/hiapp/bundle/programs/server/npm/npm-bcrypt/node_modules/bcrypt/bcrypt.js:1:97)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
Through some research, it seems that the issue is that bcrypt is platform-specific, and because my development is on OS X 10.10, but my production server is on Ubuntu 14.04, there-in lies the problem. My work around was to run npm install bcrypt from the programs/server folder, then copy that from programs/server/node_modules/bcrypt to programs/server/npm. This seems like a lot of manual steps.
I am just about to re-deploy my app with some fixes, and I am worried that I am going to have to again perform the same steps. Is there a better way to deploy a Meteor app where you do not run into this issue? My procedure currently is:
Run meteor build
scp resulting tarball to my server (Digital Ocean)
explode the tarball in my app users home directory
ADDED STEPS: recompile bcrypt and copy the directory over as stated above
I am guessing the auto-refresh will be broken as the first time the server tries to load the new libraries it will explode in fiery glory. Would it be better to simply clone the GIT repo on the server and do the build straight from there, or can I use mup or any other tools to help smoothen the deployment process?
There are two ways of getting around this time-consuming problem which are totally dependant on how you deploy.
Manual deploy
If you are manually deploying your app then make sure that you are using node v0.10.361 and only that. Meteor does not work well with node v0.12.x. More specifically, the fibers module causes a lot of problems, it chokes on various errors2.
The following is the procedure that fixed it for me3, 4:
Remove the bcrypt module from the npm directory:
$ cd path_to_your_app/bundle/programs/server
$ rm -rf npm/npm-bcrypt/node_modules/bcrypt/
Install the bcrypt module into the node_modules directory first. This builds bcrypt against the server's OS:
$ npm install bcrypt
Move the newly created bcrypt module into the npm directory:
$ cp -r node_modules/bcrypt npm/npm-bcrypt/node_modules/bcrypt
Finally, restart the app, mogodb and any web server processes such as nginx6, through upstart if you have it configured. Under the heading sanity steps below you can perform if the steps outlined above have not fixed it for you.
Using Meteor Up (mup)
If you are using mup then the process is much easier as other answers on this thread point out. However, there are cases where errors still arise including the invalid ELF header error. Make sure you have the most recent version of mup npm update mup -g.
The first step is to remove any pre-existing app and nodejs package. Mup installs the app into /opt/ and within there you can find your_app and nodejs. Remove them.
Verify that you have the correct node version, 0.10.36 only1 and the following settings, in the mup.json file:
{
...
"setupMongo": true,
"setupNode": true,
"nodeVersion" : "0.10.36",
"setupPhantom": true,
"enableUploadProgressBar": true,
// Application name (No spaces)
"appName": "your_app",
// Location of app (local directory)
"app": ".",
...
}
Run:
$ mup setup
$ mup deploy
Navigate to the server folder on your server and rebuild modules:
$ cd /opt/your_app/app/programs/server
$ npm rebuild
$ npm install
Optional: $ sudo npm update node-gyp -g
Finally, restart the app, mogodb and any web server processes such as nginx6. After the above steps, you may want to look at sanity steps below for more debugging options.
Sanity steps
There are a few other steps you can perform:
Note that apache may also bind itself to the same port that nginx is running on. Look at your app's error logs and your web server's error logs to see if there are any issues. Stop apache via sudo service apache2 stop or brute force close (not recommended) any running processes on port 80.
Then remove or move the apache2 conf file to prevent it from starting up again. All conf files are located in /etc/init or /etc/init.d.
Use $ mup logs -f to view mup logs. To view errors from your app, the end of the file, /var/log/upstart/your_app.log is useful (assuming you have upstart configured).
If using nginx make sure your directories are symlinked.
$ ln -s /etc/nginx/sites-available/your_server_config /etc/nginx/sites-enabled/your_server_config
Moreover, make sure that you have specified a default_server5 in your_server_config.
Check that mongodb can run.
References
Meteor version 1.0.4.1 (released near the end of March 2015) requires that node version 0.10.36 be installed. I recommend using the node version manager, n, to control what version of node is running on your server at any one time. Link.
The dreaded [XXX.XX.XXX.XX] Error: '/opt/your_app/programs/server/node_modules/fibers/bin/linux-x64-v8-3.28/fibers.node' is missing. Try reinstalling 'node-fibers'? error. Link.
The procedure is modified from here: Link.
For your information, I used DigitalOcean's very helpful guide on deploying a meteor app to a server. Link.
Specifying a default_server. Link.
Common processes to restart are: sudo service mongod/nginx/yourapp restart.
I had the exact same issue - I switched to using Meteor Up (MUP) instead and the problem went away. Not to mention its a lot more straightforward!
I followed this tutorial on youtube - https://www.youtube.com/watch?v=WLGdXtZMmiI which covers deploying using MUP to Digital Ocean.
MUP's github page specifically mentions that it handles binary NPM modules - https://github.com/arunoda/meteor-up#binary-npm-module-support
Hope that's some help!
Running npm rebuild at bundle/programs/server/npm/ should take care of rebuilding the modules for the server platform, regardless of the original app being bundled at Linux or MacOS.
I had the same issue and did the following to fix it:
Uninstall nodejs
sudo apt-get remove nodejs
Remove any remaining files
rm -rf ~/.nvm ~/.npm
sudo rm -rf /usr/bin/node /opt/nodejs /usr/lib/node_modules /usr/local/lib/node_modules
Upgrade node version from the default setting in mup.json
"nodeVersion": "0.10.33",
Run mup setup and deploy
mup setup
mup deploy
I followed the installation guide at https://www.cloudcontrol.com/dev-center/Add-on%20Documentation/Data%20Storage/MemCachier. The memcachier server is up and running, I tested it from the command line. But my cloudcontrol app isn't able to access it.
Here's the error in our logs:
Info MemcachedError: error 40 from memcached_set: FAILED TO SEND AUTHENTICATION TO SERVER, no mechanism available, host: [my-memcachier-server-url]:11211 -> libmemcached/sasl.cc:221
Notice No worthy mechs found
This seems to be a SASL-related issue. Is it possible that cctrl does not have the correct sasl2 libraries installed? Did anyone else experience this problem?
Further info:
django-pylibmc==0.5.0 and pylibmc==1.4.1 in requirements.txt
url and credentials are read from the cctrl environment correctly
This is caused by the libmemched version bundled with the buildpack missing a patch (https://bugs.launchpad.net/libmemcached/+bug/1381160). Because it is a stackoverflow bug, it can work systematically on your machine while it systematically breaks in the container. I will update the python buildpack to use the patched libmemcached library from the stack.
In the meantime you can try to achieve this manually by setting the LD_LIBRARY_PATH environment variable to /usr/local/lib either via config add-on or web: env LD_LIBRARY_PATH=/usr/local/lib <your_command> in the Procfile.