I am working with a community-developed OpenShift cartridge for nginx. The cartridge's build script (without any modifications) works well; it starts the nginx server with the configuration file that I provide it. However, I am trying to modify the build script so that it first changes directory into my OpenShift repository, runs npm install and then grunt build to build an Angular application that I have created.
When I do this, I continuously get the error EACCES, mkdir '/var/lib/openshift/xxxxxxxxxx/.npm' when the script gets to npm install. Some OpenShift forum posts have attempted to solve the issue, but it appears as though a different solution is required (at least in my case).
Thus, I am interested in whether or not it is possible to use npm in this way, or if I need to create a cartridge that does all of this myself.
Since we do not typically have the access required to create ~/.npm, we have to find ways of moving the npm cache (normally ~/.npm) and the npm user configuration (normally ~/.npmrc) to accessible folders to get things going. The following information comes partially from a bug report that I submitted to Redhat on this matter.
We must begin by creating an environmental variable to control the location of .npmrc. I created a file (with shell access to my application) called .env in $OPENSHIFT_DATA_DIR. Within this file, I have placed:
export NPM_CONFIG_USERCONFIG=$OPENSHIFT_HOMEDIR/app-root/build-dependencies/.npmrc
This moves the .npmrc directory to a place where we have the privileges to read/write. Naturally, I have to also create the directory .npmrc in $OPENSHIFT_HOMEDIR/app-root/build-dependencies/. Then, in my pre-start webhook/early in my build script, I have placed:
touch $OPENSHIFT_DATA_DIR/.env
This ensures that the environmental variable that configures the location of .npmrc will be accessible each time we deploy/build. Now we can move the location of the npm cache. Start by running touch on the .env file manually, and create the .npm directory in $OPENSHIFT_HOMEDIR/app-root/build-dependencies/. Run the following to complete the reconfiguration:
npm config set cache $OPENSHIFT_HOMEDIR/app-root/build-dependencies/.npm
NPM should now be accessible each time we deploy, even if we are not using the NodeJS cartridge. The above directory choices may be changed as desired.
You do not have write access to the ~/.npm directory in your gear. You might try reviewing how the native node.js cartridge is setup (https://github.com/openshift/origin-server/tree/master/cartridges/openshift-origin-cartridge-nodejs) and see if you can apply it to your custom cartridge.
Related
I have a meteor app that needs to periodically read a file located on the host's file system, outside of the app package. I am using node's fs to accomplish this, and it works fine on my (macOS) development machine.
However, when I run mup deploy to deploy it to my (Ubuntu 14) server, mup returns the following error after starting meteor:
Error: ENOENT: no such file or directory, open '/home/sam/data/all_data.json'
at Object.fs.openSync (fs.js:652:18)
at Object.fs.readFileSync (fs.js:553:33)
Does anyone know why this might be happening?
you should follow mup documentation closely. Have you seen volumes setup in mup config? Try this to solve your issue.
Reason: mup runs app in docker without any access to host file system unless specified. Volumes setup does this for you with mup deployment.
Below is the part of mup config from http://meteor-up.com/docs.html, Everything Configured, read more to get a better idea.
name: 'app',
path: '../app',
// lets you add docker volumes (optional). Can be used to
// store files between app deploys and restarts.
volumes: {
// passed as '-v /host/path:/container/path' to the docker run command
'/host/path': '/container/path',
'/second/host/path': '/second/container/path'
},
The user you have that is running your meteor build on the server needs to have access to that folder - read access. I would store the file in a different directory than the home one, because you don't want to mess it up. Either way doing something like chmod -R 444 /home/sam/data should give read access to any user for all files in that directory. You are probably running meteor as your local user(sam?) in development mode on your macOS, but the built up gets run as meteor or some other user on ubuntu, because of mup and forever.
I am running Nexus 3.0.1-01, and am using it to host both Maven repositories and NPM registries. For NPM, I have a local mirror of npmjs.org, a local NPM registry and a group that combines the two...
I have been using this with npm internally, where I can use the npm-public group as my registry and this has been working fine. So, I can use Nexus to mirror npmjs.
The next step is to take locally written npm modules and publish them to npm-releases (on my Nexus instance) so that these modules can be shared amongst the delivery teams here. I've been able to build out a package, and npm pack seems to behave.
I have run npm adduser to provide my Nexus credentials to my npm environment. I am using the same username/password I use when I log into the Nexus web app, and my user is assigned the admin role (so I should have all permissions). I can see the credentials in my .npmrc file
My registry value is still the npm-public group which combined the mirror and my local registry. I have ensured that the package.json of the module I am attempting to deploy has a "publishConfig" section that points to the url of the local registry (not the public group)
However, despite all of that, calling "npm publish" results in a 401 error...
Looking at the npm-debug.log, I can see it's attempting to call the HTTP PUT call to push the assembled tgz file to the registry, and this is returning a 401 error
I have enabled debug logging on the shiro package in the server, but I only ever see a single message thinking it needs authentication
2016-09-13 08:56:28,590+1000 DEBUG [qtp1257823896-4030] *UNKNOWN org.apache.shiro.web.filter.authc.BasicHttpAuthenticationFilter - Authentication required: sending 401 Authentication challenge response.
According to the documentation, I've done all I'm supposed to do (npm add user) but I am unable to successfully deploy an npm module to my local repository.
Are there additional options I need to use when calling npm publish? Are there additional settings I need to make to the hosted npm repository in my server that will allow me to publish to it? I pretty much created it using the default values. Have I missed a step that is preventing me from deploying to my hosted npm registry?
Any help would be greatly appreciated, as I am stuck at the moment.
As it turns out, I did not have the Npm Bearer Token Realm in my list of active realms. Once I moved it to Active, the publish completed successfully!
Additonally to #EdH's answer we discovered that the format of .npmrc has changed so base64 encoded _auth will not work anymore... and the token has to be created by logging into the repo.
old .npmrc
registry=https://host/repo
_auth=12afdjsljl123213
new .npmrc
//host/repo/:_authtoken=uuidOfToken
Additionally to #Daniel's answer, I discovered that when adding user credentials/logging into npm, you can't have a trailing slash on the registry url.
Bad:
npm adduser --registry=https://repo.localhost/repository/npm-internal/
Good:
npm adduser --registry=https://repo/repository/npm-internal
Also, if you're looking to automate the login (i.e. non-interactively), I used a good tool called npm-cli-login.
npm-cli-login -u admin -p admin123 -e nick#foo.bar -r https://repo/repository/npm-internal
I realize that this post is a couple years old now, but as of struggling with this issue for many hours, I finally found what worked for me that I've not seen in many other places. The problem was that I was not specifying the _authToken within the .npmrc file. Adding this as shown below resolved the issue and I was able to successfully run npm commands without a 401 error.
.npmrc
registry=https://test.repo.com/repository/npm-group/
//test.repo.com/repository/npm-group/:_authToken=NpmToken.${NPM_TOKEN}
Another reason why you might get such an error is that you might have enabled anonymous access to the server for the 'npm Bearer Token Realm'. After disabling anonymous access you must also remove .npmrc and re-add the registry and adduser.
I am trying to build a Meteor app using meteor build --directory ../dist. Everything seems to build fine, but when I follow the instructions provided in the generated README file I get an error saying the server/main.js file can't load. When I looked, I saw that the main.js file is not there.
Is there something I need to do before I build to ensure the file exists after build?
I'm having a very difficult time trying to build the Meteor app for a production serve, and I can't seem to find any clear instructions. The Meteor doc instructions are very vague in regard to build.
I can see how the README can be confusing if not followed as intended.
The first command line states:
$ (cd programs/server && npm install)
Note the parentheses.
Those cause the command to run in a subshell, which means that your shell will remain in the same directory after the command execution is done.
However, if you only execute the inner commands, you will end up in the programs/server directory and experience what you describe.
In any case, $ node main.js should be run from the bundle's root directory.
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'm trying to deploy a site to firebase.
firebase init worked fine. I then ran firebase bootstrap and chose the tetris template. So far so good. But when I run firebase deploy I get Preparing to deploy Public Directory... and then it just hangs forever.
How can I figure out what's going wrong?
Random info in case it helps:
My firebase-tools is version 1.0.1; node is version 0.8.20; npm is version 1.4.23. I ran sudo npm install -g firebase-tools to get the CLI. I'm running on a debian chroot on Android 4.4.3 device. My wifi works fine. On a lark I even tried running sudo firebase deploy in case it depends on ICMP packets or something, but there was no difference.
Firstly, the main reason it's not working is that Node.js version 0.10 or greater is required.
However, even once you've upgraded Node (and I'd recommend getting the latest of firebase-tools too) you're likely to be attempting to deploy the directory that you ran the initial firebase init command from, or at least the folder you specified in the setup (which defaults to the folder you ran the command from).
You should change directory and run the firebase deploy command from the folder that was created by the bootstrap command - which would have been named after the name of the Firebase it was created with, and you can delete the firebase.json file created in the parent directory.
The reason is that firebase init and firebase bootstrap are two different ways of doing the same thing - getting a folder in a deployable state. firebase init is for existing projects with files that will eventually be deployed, and firebase bootstrap is for creating a project from one of the existing templates. By running both, the initial firebase init would have created a firebase.json file containing the settings specified by the prompts, and then the firebase bootstrap command would have created a whole new sub-folder with its own firebase.json for the different settings.