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.
Related
I am following a tutorial on Ionic Angular and it has come to the point where the instructor is having me publish my code to Firebase Hosting. First I used NPM to install the Firebase CLI. Then I was instructed to use the firebase init command. The issue is that the CLI doesn't seem to recognize the current directory that is selected in my terminal.
I run: cd /Users/MyUserName/myProjectsFolder/myProject/
Then I run firebase init and it displays:
You're about to initialize a Firebase project in this directory:
/Users/MyUserName
When I would expect it to read:
You're about to initialize a Firebase project in this directory:
/Users/MyUserName/myProjectsFolder/myProject
A little bit of googling found this page:
https://firebase.google.com/docs/cli/
Which includes this passage:
To initialize a new project directory, change directories in the terminal to your desired project directory and run: firebase init
Based on this I would expect the steps I took to work.
I am confused. Has anyone ever run into this behavior? Can anyone think of a way to get the CLI to function as expected?
Thanks.
Got to folder:
/Users/Username/
Search for a file with name of firebase.json and Delete it.
Reinstall firebase tool with this command (--unsafeper- to avoid
permissions error messages & use sudo):
$ sudo npm install --unsafeper- -g firebase-tools
Then, go to your pubilc folder (you have to create one) which
contains your HTML, JS, images and CSS files and use this command:
$ sudo firebase init
$ sudo firebase deploy
The reset is easy and as mentioned in the firebase
docs:
https://firebase.google.com/docs/hosting/quickstart
The reason is that you must have initiliazed a project in some parent directory (of this myProject folder) in the past. Somehow firebase sees that project in that directory rather than initializing a new project in the current path.
Solution:
Check the parent directories of the path where you want to initialize a firebase project now. Delete / Move the firebase files from that folder and then you should be able to initialize a project in the current directory.
For example:
I also faced the same problem.
I was trying to initialize a project in this path:
D:\Work\Projects\myProject
But somehow it always got initialized in this path:
D:\Work
After some searching it turned out that the reason was that I had initialized a project in
D:\Work directory. I moved those files to another folder and that solved the problem.
I was also facing this problem and windows not able to recognize the firebase. I don't know the exact reason why it was behaving in such a manner but it solved the problem.
1) I installed the firebase-tools using a command on command prompt
npm install -g firebase-tools
and it didn't work.
2) I restarted the machine.
3) then again I executed the same command from step 1) npm install -g firebase-tools
and it worked.
Was trying to do this and discovered a command that allows "firebase" as a command.curl -sL https://firebase.tools | bash This will allow $ firebase login and $ firebase init to work.
I was facing the same issue. After checking the log I figured out that the Authentication token was expired from my firebase cli login session. So I logged out and Logged-In again to the firebase cli using Firebase logout And firebase login command. Problem solved.
To check out your issue go to firebase log using firebase-debug.log command.
And take required steps.
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 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.
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.
How to deploy a app with password in meteor using linux. It's deploy good when with out set password.But i need to deploy app with password in meteor. I did but gets some error messages i didn't understand the following messages.So please see the below deployment process and suggestions me what to do?
[root#localhost myapp]# meteor deploy myapp.meteor.com --password
deploy: the --password option needs a value.
Try 'meteor help deploy' for help.
[root#localhost myapp]# meteor deploy myapp.meteor.com 123456
deploy: too many arguments.
Usage: meteor deploy <site> [--settings settings.json] [--debug] [--delete]
Deploys the project in your current directory to Meteor's servers.
You can deploy to any available name under 'meteor.com'
without any additional configuration, for example,
'myapp.meteor.com'. If you deploy to a custom domain, such as
'myapp.mydomain.com', then you'll also need to configure your domain's
DNS records. See the Meteor docs for details.
The --settings flag can be used to pass deploy-specific information to
the application. It will be available at runtime in Meteor.settings, but only
on the server. If the object contains a key named 'public', then
Meteor.settings.public will also be available on the client. The argument
is the name of a file containing the JSON data to use. The settings will
persist across deployments until you again specify a settings file. To
unset Meteor.settings, pass an empty settings file.
The --delete flag permanently removes a deployed application, including
all of its stored data.
Options:
--delete, -D permanently delete this deployment
--debug deploy in debug mode (don't minify, etc)
--settings set optional data for Meteor.settings
--star a star (tarball) to deploy instead of the current Meteor app
[root#localhost myapp]#
Perhaps you should use both command and option:
meteor deploy myapp.meteor.com --password 123456