You may specify an explicit list of local users to chroot() to their home directory. If chroot_local_user is YES, then this list becomes a list of users to NOT chroot().
(Warning! chroot’ing can be very dangerous. If using chroot, make sure that the user does not have write access to the top level directory within the chroot)
uncomment and update the following entries to match your information:
# vi vars
set_var EASYRSA_REQ_COUNTRY “CN”
set_var EASYRSA_REQ_PROVINCE “Jiangsu”
set_var EASYRSA_REQ_CITY “Suzhou”
set_var EASYRSA_REQ_ORG “Betterit”
set_var EASYRSA_REQ_EMAIL “admin@betterit.info”
set_var EASYRSA_REQ_OU “IT”
Save and close the file.
Before generating a CA keypair first we need to initialize a new PKI with:
# ./easyrsa init-pki
The next step is to build the CA:
# ./easyrsa build-ca
You’ll be asked to set a password for the CA key and enter a common name for your CA.
Once completed, the script will create two files — CA public certificate ca.crt and CA private key ca.key.
Now that the Certificate Authority (CA) is created, you can use it to sign certificate requests for one or multiple OpenVPN servers and clients.
Note:If you don’t want to be prompted for a password each time you sign your certificates, run the build-ca command using the nopass option: ./easyrsa build-ca nopass.
DH parameters of size 2048 created at /usr/local/EasyRSA-3.0.5/pki/dh.pem
[root@iZbp16cdvzk4ribfwjca03Z EasyRSA-3.0.5]#
Copy the dh.pem file to the /etc/openvpn directory:
# cp pki/dh.pem /etc/openvpn/
generate a HMAC signature using the openvpn binary:
# openvpn –genkey –secret ta.key
Once completed copy the ta.key file to the /etc/openvpn directory:
# cp ta.key /etc/openvpn/
Creating Server Certificate and Private Key
./easyrsa gen-req vpnsvr01 nopass
We are using the nopass argument because we want to start the OpenVPN server without a password input. Also in this example, we are using vpnsvr01 as a server name (entity) identifier. If you choose a different name for your server don’t forget to adjust the instructions below where the server name is used.
The command will create two files, a private key (vpnsvr01.key) and a certificate request file (vpnsvr01.req).
Copy the private key to the /etc/openvpn directory:
# cp pki/private/vpnsvr01.key /etc/openvpn/
run the following command to sign the request:
./easyrsa sign-req server vpnsvr01
The first argument can either be server or client and the second one is the server short (entity) name.
# cp pki/ca.crt /etc/openvpn/
# cp pki/issued/vpnsvr01.crt /etc/openvpn/
Upon completing the steps outlined in this section, you should have the following new files on your OpenVPN server:
/etc/openvpn/ca.crt
/etc/openvpn/dh.pem
/etc/openvpn/ta.key
/etc/openvpn/vpnsvr01.crt
/etc/openvpn/vpnsvr01.key
Configuring the OpenVPN Service
We will use the sample configuration file provided with OpenVPN installation package as a starting point and then add our own custom configuration options to it.
Before adding the nat rule you need to know the public network interface of your CentOS OpenVPN Server. You can easily find the interface by running the following command:
ip -o -4 route show to default | awk ‘{print $5}’
In our case, the interface is named eth0 as shown on the output below. Your interface may have a different name.
The following command will allow the traffic to leave the VPN, giving your VPN clients access to the Internet. Don’t forget to replace eth0 to match the name of public network interface you found in the previous command.
Now we need to edit the file to match our server settings and configuration.
# vi openvpn-clients/base/client.conf
Find the remote directive and change the default placeholder with the public IP address of your OpenVPN server:
# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote YOUR_SERVER_IP 1194
Locate and comment the ca, cert, and key directives. The certs and keys will be added within the configuration file:
# SSL/TLS parms.
# See the server config file for more
# description. It’s best to use
# a separate .crt/.key file pair
# for each client. A single ca
# file can be used for all clients.
# ca ca.crt
# cert client.crt
# key client.key
Append the following lines at the end of the file to match the server settings:
auth SHA256
key-direction 1
Once you are done, the server configuration file should look something like this:
client
dev tun
proto udp
remote 118.31.38.47 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
verb 3
auth SHA256
key-direction 1
Next, create a simple bash script that will merge the base configuration and files with the client certificate and key, and store the generated configuration in the openvpn-clients/configs directory.
vi openvpn-clients/gen_config.sh
#!/bin/bash
FILES_DIR=/etc/openvpn/openvpn-clients/files
BASE_DIR=/etc/openvpn/openvpn-clients/base
CONFIGS_DIR=/etc/openvpn/openvpn-clients/configs
BASE_CONF=${BASE_DIR}/client.conf
CA_FILE=${BASE_DIR}/ca.crt
TA_FILE=${BASE_DIR}/ta.key
CLIENT_CERT=${FILES_DIR}/${1}.crt
CLIENT_KEY=${FILES_DIR}/${1}.key
# Test for files
for i in “$BASE_CONF” “$CA_FILE” “$TA_FILE” “$CLIENT_CERT” “$CLIENT_KEY”; do
if [[ ! -f $i ]]; then
echo ” The file $i does not exist”
exit 1
fi
if [[ ! -r $i ]]; then
echo ” The file $i is not readable.”
exit 1
fi
done
# Generate client config
cat > ${CONFIGS_DIR}/${1}.ovpn <<EOF
$(cat ${BASE_CONF})
<key>
$(cat ${CLIENT_KEY})
</key>
<cert>
$(cat ${CLIENT_CERT})
</cert>
<ca>
$(cat ${CA_FILE})
</ca>
<tls-auth>
$(cat ${TA_FILE})
</tls-auth>
EOF
Save the file and make it executable by running:
chmod u+x openvpn-clients/gen_config.sh
Creating Client Certificate Private Key and Configuration
In this example the name of the first VPN client will be david.
# cd /usr/local/EasyRSA-3.0.5/
# ./easyrsa gen-req david nopass
The command will create two files, a private key (david.key) and a certificate request file (david.req).
Copy the private key david.key to the /etc/openvpn/openvpn-clients/files directory you created in the previous section:
The basic procedure is to start the mongod instances that will become members of the replica set, configure the replica set itself, and then add the mongod instances to it.
Before you can deploy a replica set, you must install MongoDB on each system that will be part of your replica set.
1、在每台机器上下载解压mongodb安装包
curl -O https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel70-3.4.21.tgz tar -zxvf mongodb-linux-x86_64-rhel70-3.4.21.tgz mv mongodb-linux-x86_64-rhel70-3.4.21/ /usr/local/mongodb
注：Copy the keyfile to each server hosting the replica set members. Ensure that the user running the mongod instances is the owner of the file and can access the keyfile.
The following db.updateUser() method completely replaces the user’s customData and roles data:
use products
db.updateUser( “appClient01”,
{
customData : { employeeId : “0x3039” },
roles : [
{ role : “read”, db : “assets” }
]
}
)
The user appClient01 in the products database now has the following user information:
{
“_id” : “products.appClient01”,
“user” : “appClient01”,
“db” : “products”,
“customData” : { “employeeId” : “0x3039” },
“roles” : [
{ “role” : “read”,
“db” : “assets”
}
]
}
5.分配用户更多权限：
Example
Given a user accountUser01 in the products database with the following roles:
“roles” : [
{ “role” : “assetsReader”,
“db” : “assets”
}
]
The following grantRolesToUser() operation gives accountUser01 the readWrite role on the products database and the read role on the stock database.
use products
db.grantRolesToUser(
“accountUser01”,
[ “readWrite” , { role: “read”, db: “stock” } ],
{ w: “majority” , wtimeout: 4000 }
)
The user accountUser01 in the products database now has the following roles:
“roles” : [
{ “role” : “assetsReader”,
“db” : “assets”
},
{ “role” : “read”,
“db” : “stock”
},
{ “role” : “readWrite”,
“db” : “products”
}
]
6.撤销用户相关权限：
Example
The accountUser01 user in the products database has the following roles:
“roles” : [
{ “role” : “assetsReader”,
“db” : “assets”
},
{ “role” : “read”,
“db” : “stock”
},
{ “role” : “readWrite”,
“db” : “products”
}
]
The following db.revokeRolesFromUser() method removes the two of the user’s roles: the read role on the stock database and the readWrite role on the products database, which is also the database on which the method runs:
use products
db.revokeRolesFromUser( “accountUser01”,
[ { role: “read”, db: “stock” }, “readWrite” ],
{ w: “majority” }
)
The user accountUser01 user in the products database now has only one remaining role:
All GitLab packages are posted to our package server and can be downloaded.
GitLab EE: for official Enterprise Edition releases
GitLab CE: for official Community Edition releases
Unstable: for release candidates and other unstable versions
Browse to the repository for the type of package you would like, in order to see the list of packages that are available. There are multiple packages for a single version, one for each supported distribution type. Next to the filename is a label indicating the distribution, as the file names may be the same.
Locate the desired package for the version and distribution you want to use, and click on the filename to download.
2.Installing the GitLab Package
With the desired package downloaded, use your systems package management tool to install it. For example:
Change http://gitlab.example.com to the URL at which you want to access your GitLab instance. Installation will automatically configure and start GitLab at that URL.
On your first visit, you’ll be redirected to a password reset screen. Provide the password for the initial administrator account and you will be redirected back to the login screen. Use the default account’s username root to login.
