Use Sinopia to set up private NPM services

Why do I need to set up private NPM

  • Private packages are intended for internal use only, not git+ SSH, which feels unelegant, and you want to be able to configure permissions accordingly
  • The package download on NPM is very slow. If you want to cache the downloaded package on the server, check the update first. If there is no update, the cache will be removed directly
  • Public packages go to the public repository and private packages go to the private repository of the internal server when downloading

Why write this article

When writing this article, I have seen several good articles written by the great gods. Here I would like to concentrate on a summary, and explain the pits not mentioned in the existing article. Here are some good articles:

  • Use Sinopia to build a private NPM repository
  • Sinopia | build NPM warehouse from scratch

Introduce sinopia

The introduction and pros and cons of Sinopia are not covered in detail in the previous two articles

Deployment installation and use

Install Sinopia and boot (assuming you have installed the Node environment)

$ npm install sinopia -g
$ sinopia

Then open the browser to access the address http://localhost:4873/, which is successfully displayed normally, 4873 is the default port

Configure the NPM agent

Once Sinopia is started, the NPM agent used by the client is first set up via NPM set Registry http://localhost:4873/, and then it is ready for normal use

Add users and logins

$NPM adduser --registry http://localhost:4873 // Enter $NPM login // enter as prompted

Once logged in, you can publish to the private NPM and refresh http://localhost:4873/ to see the package you just uploaded.

Note: You won’t be able to release a package name + version number already exists in the public warehouse package, because when released, sinopia public warehouse will first go to your configuration (can be specified through a configuration file, the default is http://registry.npmjs.org) to check, Upload packages to Sinopia is allowed only after check passes

configuration

The feature of Sinopia is that it creates its own files in the directory you’re running in. In cases where no configuration file is specified, the default directory is the installation directory. You can specify the directory to run with sinopia -c path/config.yaml

The default directory has two files: config.yaml and storage. Htpasswd is automatically created after the user is added.

Config. yaml — Configures the access permission, proxy, file storage path and other configuration information storage — Cache NPM package directory htpasswd — Saves the user account password and other information

config.yaml: configures access permissions, proxies, file storage paths, and other configuration information

# This is the default config file. It allows all users to do anything, # so don't use it on production systems. # # Look here for more config file examples: # https://github.com/rlidwka/sinopia/tree/master/conf # # path to a directory with all packages storage: /storage // Directory where the NPM package is stored auth: htpasswd: file: # Maximum amount of users allowed to register, defaults to "+inf". # You can set this to -1 to disable registration. max_users: # A list of other Known repositories we can talk to Uplinks: NPMJS: url: HTTP: / / http://registry.npmjs.org/ / / the default for the NPM's website packages: / / configure permissions management '@ * / *' : # scoped packages access: $all the publish: $authenticated '*': # allow all users (including non-authenticated users) to read and # publish all packages # # you can specify usernames/groupnames (depending on your auth plugin) # and three keywords: "$all", "$anonymous", "$authenticated" access: $all # allow all known users to publish packages # (anyone can register by default, remember?) publish: $authenticated # if package is not available locally, proxy requests to 'npmjs' registry proxy: npmjs # log settings logs: - {type: stdout, format: pretty, level: http} #- {type: file, path: sinopia.log, level: info} # you can specify listen address (or simply a port) listen: Localhost :4873 // By default, it can only be accessed from the local computer. If you change localhost to 0.0.0.0, you can access the Internet

Htpasswd configuration

Yaml max_users: -1 means that we set the maximum number of users to -1, which means that the NPM adduser command is disabled to create users, but the htpasswd file in the directory can still be initialized to open the htpasswd file

zhangsan:{SHA}????????????????? = : autocreated T15:2016-02-05 33:46. 238 z lisi: {SHA}?????????????????????????? = : autocreated T15 2016-02-05: they. 960 z wangwu: {SHA}?????????????????????????? = : autocreated T17:2016-02-05 59:05. 041 z

The password is clearly encrypted, but the encryption algorithm is simple: simple SHA1 hash, then converted to Base64, followed by a timestamp. Even so, we still don’t know how to add users? Don’t be afraid!!!!! Htpasswd-for-sinopia is a handy add-on to htpasswd-for-sinopia, written by the author himself. Here’s a quick introduction to htpasswd-for-sinopia:

$NPM install htpasswd-for-sinopia -g $sinopia-adduser Enter the username and password $vim htpasswd as prompted. // Check htpasswd and find that the information you just entered is already lying in it

Packages configuration (as described in this section of the previous article)

The configuration is roughly divided into two parts, one starting with @weflex/* and the other with the wildcard *.

This, of course, matches the name field in package.json, such that it matches the first configuration and Express matches the second.

The purpose of this configuration is to use NPM scoped name (@company) to refer to the WeFlex app project.

Next, there are three basic Settings under each named filter:

Access: specifies the type of users that can install the matched project. Publish: specifies the type of users that can publish the matched project. Proxy: specifies the type of users that can install the matched project. As the name implies, the values correspond to uplinks values 1 and 2, and we usually have the following optional configurations:

$all indicates that all users can perform operations. $authenticated indicates that only authenticated users can perform operations. $anonymous indicates that only anonymous users can perform operations (usually useless) In one or more users, thus explicitly specifying which users can perform matching operations after configuration is complete before running:

$ sinopia -c config.yml

Used with Sinopia

Pm2: process daemon management tool

$ npm install -g pm2

$ pm2 start `which sinopia`

More operational reference wohugb. Gitbooks. IO/pm2 / content…

NRM: NPM image address management tool

$NRM add sinopia http://localhost:4873 $// Install NRM $NPM install -g NRM $// View the list $NRM ls $// View the list $NRM ls $// Use sinopia mirror address $NRM use sinopia

security

To ensure a private NPM repository, you can add a layer of Nginx on the front end and then configure SSH as a two-layer authentication