Do Something Different...

Deploying a strongSwan IKEv2 VPN Server for Native Android 12+ Connectivity

noreply@blogger.com (Farhad) — Sun, 19 Jul 2026 09:21:35 +0000

How to Build an IKEv2 VPN Server for Android (Ubuntu 22.04)

This guide walks you through setting up a strongSwan VPN server that is natively compatible with Android's built-in IKEv2/IPSec MSCHAPv2 client.

Step 1: Install Dependencies

Update your system and install strongSwan along with the EAP plugins required for Android authentication.

sudo apt update && sudo apt upgrade -y
sudo apt install strongswan strongswan-pki libcharon-extra-plugins libcharon-extauth-plugins libstrongswan-extra-plugins -y

Step 2: Generate PKI Certificates

The server needs a Certificate Authority (CA) and a Server Certificate to prove its identity to your phone.

# 1. Create CA Key and Certificate
ipsec pki --gen --type rsa --size 4096 --outform pem > ~/ca-key.pem
ipsec pki --self --ca --lifetime 3650 --in ~/ca-key.pem --type rsa --dn "CN=VPN CA" --outform pem > ~/ca-cert.pem

# 2. Create Server Key and Certificate
# REPLACE YOUR_SERVER_IP with your actual server IP
ipsec pki --gen --type rsa --size 4096 --outform pem > ~/server-key.pem
ipsec pki --pub --in ~/server-key.pem --type rsa | ipsec pki --issue --lifetime 3650 --cacert ~/ca-cert.pem --cakey ~/ca-key.pem --dn "CN=YOUR_SERVER_IP" --san YOUR_SERVER_IP --flag serverAuth --outform pem > ~/server-cert.pem

# 3. Move to system directories
sudo cp ~/ca-cert.pem /etc/ipsec.d/cacerts/
sudo cp ~/server-cert.pem /etc/ipsec.d/certs/
sudo cp ~/server-key.pem /etc/ipsec.d/private/

Step 3: Configure strongSwan (ipsec.conf)

Edit /etc/ipsec.conf and replace its content with the following (update the IP address!):

config setup
    charondebug="ike 2, knl 2, cfg 2"
    uniqueids=yes

conn ikev2-vpn
    auto=add
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    dpdaction=clear
    dpddelay=300s
    rekey=no
    left=%any
    leftid=YOUR_SERVER_IP
    leftcert=server-cert.pem
    leftsendcert=always
    leftsubnet=0.0.0.0/0
    right=%any
    rightid=%any
    rightauth=eap-mschapv2
    rightsourceip=10.10.10.0/24
    rightdns=8.8.8.8, 8.8.4.4
    eap_identity=%identity

Step 4: Set Credentials (ipsec.secrets)

Define your server key and user login in /etc/ipsec.secrets:

: RSA "server-key.pem"
your_username : EAP "your_password"

Step 5: Networking & Firewall

Enable IP forwarding and set up NAT so the VPN has internet access.

# Enable Forwarding
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

# Open Ports
sudo ufw allow 500/udp
sudo ufw allow 4500/udp

Add the NAT rule to the top of /etc/ufw/before.rules (above *filter):

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE
COMMIT

Final Note: Remember to transfer ca-cert.pem to your phone and install it as a "CA Certificate" in settings before connecting!

Setting Up MariaDB MaxScale Binlog Proxy for backup/failover

noreply@blogger.com (Farhad) — Mon, 17 Mar 2025 08:29:00 +0000

Setting Up MariaDB MaxScale Binlog Proxy

MariaDB MaxScale Binlog Server acts as an intermediate master replication proxy. By storing binary logs and serving them to replicas, it enables scalable replication architectures, reduces primary database load, and accelerates disaster recovery.

Step 1: Install MariaDB MaxScale

Install MaxScale using the package manager appropriate for your Linux distribution, then verify the installation.

On Ubuntu/Debian:

sudo apt-get update
sudo apt-get install maxscale

On RHEL/CentOS:

sudo yum install maxscale

Verify the installation:

maxscale --version

Step 2: Configure MaxScale as a Binlog Proxy

Open MaxScale's core configuration file to establish the routing properties and specify your database backend configuration.

sudo nano /etc/maxscale.cnf

Add the following configurations for the monitor block and the binlog router service:

[maxscale]
threads=4

[Replication-Monitor]
type=monitor
module=mariadbmon
servers=primary-db,replica-db1,replica-db2
user=maxscale
password=maxpass
monitor_interval=10000
auto_failover=true

[Binlog-Server]
type=service
router=binlogrouter
servers=primary-db
user=maxscale
password=maxpass
filestem=binlog
binlogdir=/var/lib/maxscale/binlogs
gtid_strict_mode=on

Key parameters defined above:

router=binlogrouter: Directs MaxScale to act explicitly as a binlog proxy proxying system.
binlogdir: The dedicated storage directory where MaxScale caches binary logs locally.

Step 3: Set Up Users on the Primary Database

Access the primary database instance to provision administrative credentials and replication authority to MaxScale.

mysql -u root -p

Execute the following queries to create the proxy user account and apply capabilities:

CREATE USER 'maxscale'@'%' IDENTIFIED BY 'maxpass';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'maxscale'@'%';
FLUSH PRIVILEGES;

Step 4: Start and Enable MaxScale

Register MaxScale with the system init daemon to start automatically upon booting, then initiate the runtime service process.

sudo systemctl enable maxscale
sudo systemctl start maxscale
sudo systemctl status maxscale

Step 5: Configure Replica Servers to Use MaxScale

Log into each of your target replica database nodes. Point their data-fetching routes directly to your MaxScale proxy instance instead of targeting the primary database node infrastructure directly.

CHANGE MASTER TO
    MASTER_HOST='maxscale-server-ip',
    MASTER_PORT=3306,
    MASTER_USER='maxscale',
    MASTER_PASSWORD='maxpass',
    MASTER_LOG_FILE='binlog.000001',
    MASTER_LOG_POS=4;

START SLAVE;

Verify that your data stream pipeline status reflects normal active operation:

SHOW SLAVE STATUS\G;

Conclusion: Implementing the MariaDB MaxScale Binlog Proxy architecture successfully insulates your primary production database against high-volume read replica scaling loads, provides a robust localized binlog caching layer for fast disaster recovery, and automates high-availability database cluster failovers.

Deploying a laravel app using nginx alias

noreply@blogger.com (Farhad) — Fri, 15 Dec 2023 16:29:00 +0000

        
           
    server {
    listen 80;
    server_name subdomian.example.com;
    root /var/www/mainapp/;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Content-Type-Options "nosniff";

    index index.html index.htm index.php;

    charset utf-8;
    error_log  /var/log/nginx/error.log  warn;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    error_page 404 /index.php;

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
    }


        location  /laravelapp {
        alias  /var/www/mainapp/laravelapp/public;
        index   index.php index.html index.html;
        try_files  $uri $uri/  @nested;

        location ~ \.php$ {
            fastcgi_pass   unix:/var/run/php/php8.1-fpm.sock;
            fastcgi_index   index.php;
            fastcgi_param  SCRIPT_FILENAME  $request_filename;
            include        fastcgi_params;
         }
     }


     location @nested {
        rewrite /laravelapp/(.*)$ /laravelapp/index.php?/$1 last;
     }

     location ~ /\.(?!well-known).* {
        deny all;
     }

}

Get wifi password easily from a windows PC

noreply@blogger.com (Farhad) — Thu, 14 Sep 2023 11:56:00 +0000

How to get saved wifi password from a windows machines easily.

Vulnerability: A hacker can easily use this trick if he can access a windows machine, get all the saved wifi password, implant a backdoor into the machine and try to access other devices connected to that wifi. So, keep secure your windows PC by using latest antivirus, firewall.

Let's get started.....

Open cmd and type "netsh wlan show profile"

It will show all the saved wifi profile in your PC.

Now select a profile to get it's password.

netsh wlan show profile name="Finix" key=clear

It will show detail of the SSID with a value "Key Content" under "Security Settings" that is the wifi password.

Have fun.

Setup a Multi-Protocol VPN Server Using SoftEther on Centos7

noreply@blogger.com (Farhad) — Wed, 22 Feb 2023 04:33:00 +0000

Introduction

This article explains how to install and configure a multi-protocol VPN server using the SoftEther package. We enable and configure OpenVPN and L2TP over IPSec and SSTP VPN Servers on Linux.

What is SoftEther

SoftEther VPN is one of the world’s most powerful and easy-to-use multi-protocol VPN software, made by the good folks at the University of Tsukuba, Japan. It runs on Windows, Linux, Mac, FreeBSD and Solaris and is freeware and open-source. You can use SoftEther for any personal or commercial use free of charge.

Step 1: Create a Virtual Server

First, you need to create a DigitalOcean Droplet. As mentioned in SoftEther’s website, SoftEther will work on almost every Linux distro with kernel v2.4 or above,; however it’s recommended to choose one of these distributions: CentOS, Fedora, or Red Hat Enterprise Linux.

Personally I have tried it on Ubuntu, CentOS and Fedora, both 32 and 64 bit editions, and it has worked perfectly.

Step 2: Update your Server Software

Using the command below, update and upgrade your server software packages to the latest version:

Debian / Ubuntu:

apt-get update && apt-get upgrade

CentOS / Fedora:

yum upgrade

Step 3: Download SoftEther

You can download the latest SoftEther server package for Linux from their website:

Download SoftEther

Unfortunately, there is no way of getting the latest version through package managers (or even using a single url) at the moment. Therefore you have to browse their website using a desktop browser to download the package. There are a couple of ways of dealing with this: First, browse their website on your own computer and then depending on your server configuration (OS, x86/x64, etc.) find the link to the appropriate package then use wget to download the package to your server. Alternatively, you can use a terminal based web browser such as lynx to browse the SoftEther website and download the right package.

Here’s how to do it using lynx:

First install lynx on your server:

Debian / Ubuntu:

apt-get install lynx -y

CentOS / Fedora:

yum install lynx -y

Now using the command below browse the SoftEther download webpage:

lynx http://www.softether-download.com/files/softether/

This page contains all versions of the SoftEther available. Choose which version you want (in this tutorial we use v2.00-9387-rtm-2013.09.16) and then press Enter to go to the link. Now choose Linux and in the next page choose SoftEther VPN Server. Depending on your server hardware architecture, choose a package; the 32bit - Intel x86 and 64bit - Intel x64 or AMD64 work for DigitalOcean 32bit or 64bit droplets. Finally download the tar file from the next page by pressing the “D” key on the link, and choose “Save to disk” when asked by Lynx. After the file is saved, we can press “Q” to quit Lynx and move on with the installation.

Step 4: Install and Configure SoftEther

Now we have to extract the package we received from the SoftEther download page and compile it. The package used in this tutorial is named softether-vpnserver-v2.00-9387-rtm-2013.09.16-linux-x86-32bit.tar.gz so we will extract it using the command below:

 tar xzvf softether-vpnserver-v2.00-9387-rtm-2013.09.16-linux-x86-32bit.tar.gz

After extracting it, a directory named vpnserver will be created in the working folder. In order to compile SoftEther, the following tools and packages must be installed on your server:

make, gccbinutils (gcc), libc (glibc), zlib, openssl, readline, and ncurses

Make sure these are installed. You can install all the packages necessary to build SoftEther using the command below:

Debian / Ubuntu:

apt-get install build-essential -y

CentOS / Fedora:

yum groupinstall "Development Tools"

Note: On Fedora, I have found that the gcc package doesn’t get installed using the command above so you have to install it manually using yum install gcc.

Now that we have all the necessary packages installed, we can compile SoftEther using the following command:

First “cd” into vpnserver directory:

cd vpnserver

And now run “make” to compile SoftEther into an executable file:

make

SoftEther will ask you to read and agree with its License Agreement. Select 1 to read the agreement, again to confirm read, and finally to agree to the License Agreement.

SoftEther is now compiled and made into executable files (vpnserver and vpncmd). If the process fails, check if you have all of the requirement packages installed.

Now that SoftEther is compiled we can move the vpnserver directory to someplace else, here we move it to usr/local:

cd ..
mv vpnserver /usr/local
cd /usr/local/vpnserver/

And then change the files permission in order to protect them:

chmod 600 *
chmod 700 vpnserver
chmod 700 vpncmd

If you like SoftEther to start as a service on startup create a file named vpnserver in /etc/init.d directory and change it to the following:

First create and open the file using vi or nano:

vi /etc/init.d/vpnserver

And paste the following into the file:

#!/bin/sh
# chkconfig: 2345 99 01
# description: SoftEther VPN Server
DAEMON=/usr/local/vpnserver/vpnserver
LOCK=/var/lock/subsys/vpnserver
test -x $DAEMON || exit 0
case "$1" in
start)
$DAEMON start
touch $LOCK
;;
stop)
$DAEMON stop
rm $LOCK
;;
restart)
$DAEMON stop
sleep 3
$DAEMON start
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac
exit 0

Finally save and close the file by pressing esc and typing :wq to close vim.

We have to make a directory at /var/lock/subsys if one does not exist:

mkdir /var/lock/subsys

Now change the permission for the startup script and start vpnserver using command below:

chmod 755 /etc/init.d/vpnserver && /etc/init.d/vpnserver start

Use the command below make it to run at startup:

Debian / Ubuntu:

update-rc.d vpnserver defaults

CentOS / Fedora:

chkconfig --add vpnserver

SoftEther VPN Server is now installed and configured to run at startup. Finally, we have to check if the VPN server is working:

cd /usr/local/vpnserver
./vpncmd

Now press 3 to choose Use of VPN Tools and then type:

check

If all of the checks pass, then your server is ready to be a SoftEther VPN server and you can move on to the next step. Type “exit” to exit VPN Tools.

There are two ways to configure SoftEther VPN server: you can use the Windows based server manager to manage and configure any number of SoftEther VPN servers from remotely; or use the built-in vpncmd tool to configure your servers.

You can download SoftEther Server Manager for Windows using their website and do the configuration using the GUI that it provides, which is a preferable way if you are a Windows user.

Here we use vpncmd to configure our VPN server.

Step 5: Change Admin Password

Now that you have SoftEther VPN server installed, you have to assign an administrator password in order to use with SoftEther. You can do this using vpncmd which is SoftEther’s command line based administration tool:

./vpncmd

Press 1 to select “Management of VPN Server or VPN Bridge”, then press Enter without typing anything to connect to the localhost server, and again press Enter without inputting anything to connect to server by server admin mode.

Then use command below to change admin password:

ServerPasswordSet

Step 6: Create A Virtual Hub

To use SoftEther we must first create a Virtual Hub. Here as an example we create a hub named VPN, in order to do that enter command below in the vpncmd tool:

HubCreate VPN

Next you will be asked to enter an administrator password for the hub. This password will be used whenever you are not logged in as server admin mode, and you want to manage that specific hub.

Now select the Virtual Hub you created using this command:

Hub VPN

Step 7: Enable SecureNAT

There are two ways of connecting your hubs to the server network: using a Local Bridge connection or using the SecureNAT function.

You can use each one separately, but using these two together will cause problems.

Here we use SecureNAT, which is very easy to setup and works pretty well in most situations. You could also use Local Bridge, but then you have to install and configure a DHCP Server too.

SecureNAT is a combination of Virtual NAT and DHCP Server function. You can enable SecureNAT using the command below:

SecureNatEnable

Step 8: Create and Manage Users

Now we have to create users for our Virtual Hub to use the VPN. We can create users for our Virtual Hub using the command UserCreate and view the list of current users by UserList. Users can be added to groups and can even have different types of authentication modes (including: Password, Certificate, RADIUS, NTLM, etc.).

By using command UserCreate we create a user named “test”:

UserCreate test

The default type of authentication is Password but we can change it to a different type using commands below:

UserNTLMSet for NT Domain Authentication

UserPasswordSet for Password Authentication

UserAnonymousSet for Anonymous Authentication

UserRadiusSet for RADIUS Authentication

UserCertSet for Individual Certificate Authentication

UserSignedSet for Signed Certificate Authentication

In this tutorial we use Password as the user authentication mode for our test user, so using this command set a password for user test:

UserPasswordSet test

Step 9: Setup L2TP/IPSec

To enable L2TP/IPsec VPN server you can use the command below:

IPsecEnable

After entering this command, you will be asked to configure the L2TP server functions:

Enable L2TP over IPsec Server Function: Choose yes to enable L2TP VPN over IPSec with pre-shared key encryption. Now you can make VPN connections to this server using iPhone, Android, Windows, and Mac OS X devices.

Enable Raw L2TP Server Function: This will enable L2TP VPN for clients with no IPSec encryption.

Enable EtherIP / L2TPv3 over IPsec Server Function: Routers which are compatible with EtherIP / L2TPv3 over IPsec can connect to this server by enabling this function.

Pre Shared Key for IPsec: Enter a pre-shared key to use with L2TP VPN.

Default Virtual HUB in a case of omitting the HUB on the Username: Users must specify the Virtual Hub they are trying to connect to by using Username@TargetHubName as their username when connecting. This option specifies which Virtual Hub to be used if the user does not provide such information. In our case enter VPN.

Step 10: Setup SSTP/OpenVPN

The SoftEther can clone the functions of Microsoft SSTP VPN Server and OpenVPN Server. But before we enable these we have to generate a self-signed SSL certificate for our server. You can use openssl or SoftEther’s own command to generate a SSL certificate.

Here we use SoftEther’s ServerCertRegenerate command to generate and register a self-signed SSL certificate for our server. The argument passed to command is CN (Common Name), and must be set to your host name (FQDN) or IP address:

ServerCertRegenerate [CN]

Note 1: SoftEther also comes with a built-in Dynamic DNS function, which can assign a unique and permanent hostname for your server. You can use the hostname assigned by this function for creating a SSL Certificate and connecting to your server.

Note 2: If you already have a SSL certificate or you have created one using openssl, it can be added to the server using the command ServerCertSet.

Now that we have created the certificate, we have to download the certificate to our clients and add them as trusted. Using the command below, we save the server certificate into a file named cert.cer:

ServerCertGet ~/cert.cer

Now you can download the certificate to your client using FileZilla or any other SFTP Client.

To make the certificate trusted in Windows, you have to install it in the Trusted Root Certification Authorities store. Here’s an article explaining how (read the To install a certificate chain part):

Installing a Certificate Chain

Now that we have created and registered a SSL Certificate for our server, we can enable SSTP function with this command:

SstpEnable yes

And to enable OpenVPN:

OpenVpnEnable yes /PORTS:1194

Note: OpenVPN’s default port is 1194, but you can change it to any port you want by changing the /PORTS:1194 part of the command above to your desired port or ports (yes it supports multiple ports).

After you enabled OpenVPN, you can download a sample configuration file for OpenVPN client. Here we create a sample OpenVPN configuration file and save it to my_openvpn_config.zip:

OpenVpnMakeConfig ~/my_openvpn_config.zip

Then you can download it using any SFTP client such as FileZilla and apply it to your OpenVPN clients.

SoftEther also provides a dedicated VPN Client software for both Windows and Linux. It supports a SoftEther specific protocol called Ethernet over HTTPS or SSL-VPN which is very powerful. It uses HTTPS protocol and port 443 in order to establish a VPN tunnel, and because this port is well-known, almost all firewalls, proxy servers and NATs can pass the packet. In order to use SSL-VPN protocol, you must download and install SoftEther VPN Client, which can be obtained from their website.

Step 11: Connecting to SoftEther VPN Server (Client Configuration)

Since SoftEther is a multi-protocol VPN server, there are many ways to connect to it as a client. You can choose any protocol to establish a secure connection to your server, including L2TP, SSTP, OpenVPN and an exclusive to SoftEther protocol named SSL-VPN.

Depending on the client operating system and configurations, you could use any of the mentioned protocols. However, I prefer to use SSL-VPN since it’s both secure and fast, and also as mentioned before since it uses a common and well-known port (443 or https-port), it can penetrate most of the firewalls.

Here we use SoftEther’s own VPN client software to connect to our server:

First download the SoftEther VPN Client for Linux from SoftEther’s website. We can download it using a lynx browser. Enter this command to open SoftEther’s download page:

lynx http://www.softether-download.com/files/softether/

Then just as you did when downloading the Server software, select the latest version (Here we used v2.00-9387-rtm-2013.09.16). Now choose Linux and in the next page choose SoftEther VPN Client. Now depending on your system’s hardware architecture, choose a package (The 32bit - Intel x86 and 64bit - Intel x64 or AMD64 works for DigitalOcean 32bit or 64bit droplets). Finally download the tar file from the next page by pressing the “D” key on the link, and choose Save to disk when asked by Lynx. After the file is saved, press “Q” to quit Lynx.

Extract the tar file you just downloaded using this command:

tar xzvf softether-vpnclient-v2.00-9387-rtm-2013.09.16-linux-x86-32bit.tar.gz

Note: Change softether-vpnclient-v2.00-9387-rtm-2013.09.16-linux-x86-32bit.tar.gz to your downloaded file’s name.

Now just as we did with the server, we have to compile and make vpnclient an executable file by running these commands (make sure you have the development tools mentioned in Step 4 installed on client):

cd vpnclient
make

Enter 1 three times when asked to read and accept the License Agreement, and then move the files to another directory and change permissions:

cd ..
mv vpnclient /usr/local
cd /usr/local/vpnclient/
chmod 600 *
chmod 700 vpnclient
chmod 700 vpncmd

Then start the VPN client service using this command:

./vpnclient start

To configure our client, we’re going to use vpncmd. While you’re in the vpnclient directory enter this command to run vpncmd tool:

./vpncmd

Choose 2 to enter Management of VPN Client mode, and then press enter to connect to and manage the local VPN client you just installed.

SoftEther uses Virtual Adapters to establish a connection to our VPN server, using this command create a Virtual Adapter named myadapter:

NicCreate myadapter

Now using this command, create a new VPN connection named myconnection:

AccountCreate myconnection

Then enter your SoftEther VPN server’s IP and Port number. The port number could be any port that you have set as listening on your server. By default, SoftEther listens on these four ports: 443, 992, 1194, 5555. Here as an example where we use port 443:

Destination VPN Server Host Name and Port Number: [VPN Server IP Address]:443

Note: Instead of an IP Address, you could also enter you server’s fully qualified domain name (FQDN).

Now enter the name of the Virtual Hub you’re trying to connect to on your server. In our case it is named VPN:

Destination Virtual Hub Name: VPN

Then enter the username of a user you created in your server. We created a user called test:

Connecting User Name: test

And finally enter the name of the Virtual Hub you just created:

Used Virtual Network Adapter Name: myadapter

Now our VPN connection has been created and it’s ready to be connected. One last step is to change the Authentication mode to Password since that’s how we configured our user’s authentication mode in the server:

AccountPasswordSet myconnection

When asked for, enter standard as password authentication method:

Specify standard or radius: standard

Finally we can connect our connection-- use this command to do that:

AccountConnect myconnection

You can see the connection status using this command:

AccountStatusGet myconnection

Note: In order to make your connection to the server more secure and prevent man-in-the-middle attacks, it’s best to use a SSL certificate to identify your server. This can be done easily using SoftEther. To do that, first you must download the cert file to your client as explained in Step 10 and then using CertAdd add it to your client’s trusted certificates. Then, using command AccountServerCertEnable enable certificate verification for your VPN connection.

Post Credit: https://www.digitalocean.com/community/tutorials/how-to-setup-a-multi-protocol-vpn-server-using-softether

Configure Galera Cluster with Mariadb 10.3 on Centos7 with HAproxy load balancer

noreply@blogger.com (Farhad) — Thu, 22 Dec 2022 10:21:00 +0000

Introduction

Clustering adds high availability to your database by distributing changes to different servers. In the event that one of the instances fails, others are quickly available to continue serving.

Clusters come in two general configurations, active-passive and active-active. In active-passive clusters, all writes are done on a single active server and then copied to one or more passive servers that are poised to take over only in the event of an active server failure. Some active-passive clusters also allow SELECT operations on passive nodes. In an active-active cluster, every node is read-write and a change made to one is replicated to all.

MariaDB is an open source relational database system that is fully compatible with the popular MySQL RDBMS system. You can read the official documentation for MariaDB at this page. Galera is a database clustering solution that enables you to set up multi-master clusters using synchronous replication. Galera automatically handles keeping the data on different nodes in sync while allowing you to send read and write queries to any of the nodes in the cluster. You can learn more about Galera at the official documentation page.

In this guide, you will configure an active-active MariaDB Galera cluster. For demonstration purposes, you will configure and test three CentOS 7 Droplets that will act as nodes in the cluster. This is the smallest configurable cluster.

Prerequisites

To follow along, you will need a DigitalOcean account, in addition to the following:

Three CentOS 7 Droplets with private networking enabled, each with a non-root user with sudo privileges and a firewall enabled.
- For setting up private networking on the three Droplets, follow our Private Networking Quickstart guide.
- For assistance setting up a non-root user with sudo privileges, follow our Initial Server Setup with CentOS 7 tutorial. To set up a firewall, check out the Configuring a Basic Firewall step of Additional Recommended Steps for New CentOS 7 Servers.

While the steps in this tutorial have been written for and tested against DigitalOcean Droplets, many of them should also be applicable to non-DigitalOcean servers with private networking enabled.

Step 1 — Adding the MariaDB Repositories to All Servers

In this step, you will add the relevant MariaDB package repositories to each of your three servers so that you will be able to install the right version of MariaDB used in this tutorial. Once the repositories are updated on all three servers, you will be ready to install MariaDB.

One thing to note about MariaDB is that it originated as a drop-in replacement for MySQL, so in many configuration files and startup scripts, you’ll see mysql rather than mariadb. In many cases, these are interchangeable. For consistency’s sake, we will use mariadb in this guide where either could work.

In this tutorial, you will use MariaDB version 10.4. Since this version isn’t included in the default CentOS repositories, you’ll start by adding the external CentOS repository maintained by the MariaDB project to all three of your servers.

Note: MariaDB is a well-respected provider, but not all external repositories are reliable. Be sure to install only from trusted sources.

First, you’ll add the MariaDB repository key by creating a repository file with a text editor. This tutorial will use vi:

sudo vi /etc/yum.repos.d/mariadb.repo

Next, add the following contents to the file by pressing i to enter insert mode, then adding the following:

/etc/yum.repos.d/mariadb.repo

[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.3/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

Press the esc key to return to normal mode, then type :wq to save and exit the file. If you would like to learn more about the text editor vi and its predecessor vim, take a look at our tutorial on Installing and Using the Vim Text Editor on a Cloud Server.

Once you have created the repository file, enable it with the following command:

sudo yum makecache --disablerepo='*' --enablerepo='mariadb'

The makecache command caches the repository metadata so that the package manager can install MariaDB, with --disablerepo and --enablerepo targeting the command to the mariadb repo file that you just created.

You will receive the following output:

OutputLoaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
mariadb                                                                                                                                                                              | 2.9 kB  00:00:00
(1/3): mariadb/primary_db                                                                                                                                                            |  43 kB  00:00:00
(2/3): mariadb/other_db                                                                                                                                                              | 8.3 kB  00:00:00
(3/3): mariadb/filelists_db                                                                                                                                                          | 238 kB  00:00:00
Metadata Cache Created

Once you have enabled the repository on your first server, repeat for your second and third servers.

Now that you have successfully added the package repository on all three of your servers, you’re ready to install MariaDB in the next section.

Step 2 — Installing MariaDB on All Servers

In this step, you will install the actual MariaDB packages on your three servers.

Beginning with version 10.1, the MariaDB Server and MariaDB Galera Server packages are combined, so installing MariaDB-server will automatically install Galera and several dependencies:

sudo yum install MariaDB-server MariaDB-client

You will be asked to confirm whether you would like to proceed with the installation. Enter yes to continue with the installation. You will then be prompted to accept the GPG key that authenticates the MariaDB package. Enter yes again.

When the installation is complete, start the mariadb service by running:

sudo systemctl start mariadb

Enable the mariadb service to be automatically started on boot by executing:

sudo systemctl enable mariadb

From MariaDB version 10.4 onwards, the root MariaDB user does not have a password by default. To set a password for the root user, start by logging into MariaDB:

sudo mysql -uroot

Once you’re inside the MariaDB shell, change the password by executing the following statement, replacing your_password with your desired password:

set password = password("your_password");

You will see the following output indicating that the password was set correctly:

OutputQuery OK, 0 rows affected (0.001 sec)

Exit the MariaDB shell by running the following command:

quit;

If you would like to learn more about SQL or need a quick refresher, check out our MySQL tutorial.

You now have all of the pieces necessary to begin configuring the cluster, but since you’ll be relying on rsync and policycoreutils-python in later steps to sync the servers and to control Security-Enhanced Linux (SELinux), make sure they’re installed before moving on:

sudo yum install rsync policycoreutils-python

This will confirm that the newest versions of rsync and policycoreutils-python is already available or will prompt you to upgrade or install it.

Once you have completed these steps, repeat them for your other two servers.

Now that you have installed MariaDB successfully on each of the three servers, you can proceed to the configuration step in the next section.

Step 3 — Configuring the First Node

In this step you will configure your first Galera node. Each node in the cluster needs to have a nearly identical configuration. Because of this, you will do all of the configuration on your first machine, and then copy it to the other nodes.

By default, MariaDB is configured to check the /etc/mysql/conf.d directory to get additional configuration settings from files ending in .cnf. Create a file in this directory with all of your cluster-specific directives:

sudo vi /etc/my.cnf.d/galera.cnf

Add the following configuration into the file. The configuration specifies different cluster options, details about the current server and the other servers in the cluster, and replication-related settings. Note that the IP addresses in the configuration are the private addresses of your respective servers; replace the highlighted lines with the appropriate IP addresses:

/etc/my.cnf.d/galera.cnf

[mysqld]
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so

# Galera Cluster Configuration
wsrep_cluster_name="test_cluster"
wsrep_cluster_address="gcomm://First_Node_IP,Second_Node_IP,Third_Node_IP"

# Galera Synchronization Configuration
wsrep_sst_method=rsync

# Galera Node Configuration
wsrep_node_address="This_Node_IP"
wsrep_node_name="This_Node_Name"

The first section modifies or re-asserts MariaDB/MySQL settings that will allow the cluster to function correctly. For example, Galera won’t work with MyISAM or similar non-transactional storage engines, and mysqld must not be bound to the IP address for localhost.
The “Galera Provider Configuration” section configures the MariaDB components that provide a WriteSet replication API. This means Galera in your case, since Galera is a wsrep (WriteSet Replication) provider. You specify the general parameters to configure the initial replication environment. This doesn’t require any customization, but you can learn more about Galera configuration options here.
The “Galera Cluster Configuration” section defines the cluster, identifying the cluster members by IP address or resolvable domain name and creating a name for the cluster to ensure that members join the correct group. You can change the wsrep_cluster_name to something more meaningful than test_cluster or leave it as-is, but you must update wsrep_cluster_address with the private IP addresses of your three servers.
The “Galera Synchronization Configuration” section defines how the cluster will communicate and synchronize data between members. This is used only for the state transfer that happens when a node comes online. For your initial setup, you are using rsync, because it’s commonly available and does what you’ll need for now.
The “Galera Node Configuration” section clarifies the IP address and the name of the current server. This is helpful when trying to diagnose problems in logs and for referencing each server in multiple ways. The wsrep_node_address must match the address of the machine you’re on, but you can choose any name you want in order to help you identify the node in log files.

When you are satisfied with your cluster configuration file, copy the contents into your clipboard and save and close the file.

Now that you have configured your first node successfully, you can move on to configuring the remaining nodes in the next section.

Step 4 — Configuring the Remaining Nodes

In this step, you will configure the remaining two nodes. On your second node, open the configuration file:

sudo vi /etc/mysql/my.cnf.d/galera.cnf

Paste in the configuration you copied from the first node, then update the Galera Node Configuration to use the IP address or resolvable domain name for the specific node you’re setting up. Finally, update its name, which you can set to whatever helps you identify the node in your log files:

/etc/mysql/my.cnf.d/galera.cnf

. . .
# Galera Node Configuration
wsrep_node_address="This_Node_IP"
wsrep_node_name="This_Node_Name"
. . .

Save and exit the file.

Once you have completed these steps, repeat them on the third node.

With Galera configured on all of your nodes, you’re almost ready to bring up the cluster. But before you do, make sure that the appropriate ports are open in your firewall and that a SELinux policy has been created for Galera.

Step 5 — Opening the Firewall on Every Server

In this step, you will configure your firewall so that the ports required for inter-node communication are open.

On every server, check the status of the firewall you set up in the Prerequisites section by running:

sudo firewall-cmd --list-all

In this case, only SSH, DHCP, HTTP, and HTTPS traffic is allowed through:

Outputpublic
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: ssh dhcpv6-client http https
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

If you tried to start the cluster now, it would fail because the firewall would block the connections between the nodes. To solve this problem, add rules to allow MariaDB and Galera traffic through.

Galera can make use of four ports:

3306 For MariaDB client connections and State Snapshot Transfer that use the mysqldump method.
4567 For Galera Cluster replication traffic. Multicast replication uses both UDP transport and TCP on this port.
4568 For Incremental State Transfers, or IST, the process by which a missing state is received by other nodes in the cluster.
4444 For all other State Snapshot Transfers, or SST, the mechanism by which a joiner node gets its state and data from a donor node.

In this example, you’ll open all four ports while you do your setup. Once you’ve confirmed that replication is working, you’d want to close any ports you’re not actually using and restrict traffic to just servers in the cluster.

Open the ports with the following commands:

sudo firewall-cmd --permanent --zone=public --add-port=3306/tcp
sudo firewall-cmd --permanent --zone=public --add-port=4567/tcp
sudo firewall-cmd --permanent --zone=public --add-port=4568/tcp
sudo firewall-cmd --permanent --zone=public --add-port=4444/tcp
sudo firewall-cmd --permanent --zone=public --add-port=4567/udp

Using --zone=public and --add-port= here, firewall-cmd is opening up these ports to public traffic. --permanent ensures that these rules persist.

Note: Depending on what else is running on your servers you might want to restrict access right away. To learn more about how to use FirewallD, see our tutorial How To Set Up a Firewall Using FirewallD on CentOS 7.

Now, add each server to the public zone by executing the following commands, replacing the highlighted text with the respective private IP addresses of your nodes:

sudo firewall-cmd --permanent --zone=public --add-source=galera-node-1-ip/32
sudo firewall-cmd --permanent --zone=public --add-source=galera-node-2-ip/32
sudo firewall-cmd --permanent --zone=public --add-source=galera-node-3-ip/32

Reload the firewall to apply the changes:

sudo firewall-cmd --reload

After you have configured your firewall on the first node, create the same firewall settings on the second and third node.

Now that you have configured the firewalls successfully, you’re ready to create a SELinux policy in the next step.

Step 6 — Creating a SELinux Policy

In this section, you will create a SELinux policy that will allow all the nodes in the cluster to be able to communicate with each other and perform cluster operations.

SELinux is a Linux kernel module that improves the security of operating systems with its support for access control and mandatory access control policies. It is enabled by default on CentOS 7 and restricts the MariaDB daemon from performing many activities.

In order to create the policy, you will perform various activities on the cluster with the SELinux mode set to permissive for MySQL. You will then create a policy from the logged events and finally set the SELinux mode to enforcing once the policy is installed successfully.

First, allow access to the relevant ports by running the following commands on all three servers:

sudo semanage port -a -t mysqld_port_t -p tcp 4567
sudo semanage port -a -t mysqld_port_t -p udp 4567
sudo semanage port -a -t mysqld_port_t -p tcp 4568
sudo semanage port -a -t mysqld_port_t -p tcp 4444

Note: You may receive a ValueError when allowing access to some of these ports. This means that the SELinux status of that port has already been set, which in this case will not affect the process of this tutorial.

In these commands, you are using the SELinux management tool semanage with the -a flag to add specified ports and to ignore the database server.

Next, run the following command on all three servers, which sets the MySQL SELinux domain to permissive mode temporarily.

sudo semanage permissive -a mysqld_t

This command can take a minute to complete and will not display any output.

Next, stop the database server on all the nodes so that you will be able to bootstrap the database cluster with shared SELinux policies. To do this, run the following command on all three nodes:

sudo systemctl stop mariadb

Now, bootstrap the cluster to generate inter-node communication events that will be added to the SELinux policy. On the first node, bootstrap the cluster by executing:

sudo galera_new_cluster

Create a database and table for the specific purpose of logging SST events by running the following on the first node:

mysql -u root -p -e 'CREATE DATABASE selinux;
CREATE TABLE selinux.selinux_policy (id INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(id));
INSERT INTO selinux.selinux_policy VALUES ();'

Now start the server on the second node:

sudo systemctl start mariadb

Then do the same on the third node:

sudo systemctl start mariadb

You will not see any output for the previous commands. To generate IST events, execute the following on all three servers:

mysql -u root -p -e 'INSERT INTO selinux.selinux_policy VALUES ();'

Now create and enable the SELinux policy by executing the following commands on all three servers:

sudo grep mysql /var/log/audit/audit.log | sudo audit2allow -M Galera

This first command searches for generated events in the audit.log file and pipes them to a module named Galera.pp generated by the audit2allow tool. This will result in the following output:

Output******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i Galera.pp

Next, follow the instructions in the output and use the following command to install the generated module:

sudo semodule -i Galera.pp

Now that the policy is active, disable permissive mode for the MariaDB server:

sudo semanage permissive -d mysqld_t

Now that you have successfully created a SELinux policy and enabled it, you are ready to start the cluster in the next section.

Step 7 — Starting the Cluster

In this step, you will start your MariaDB cluster. To begin, you need to stop the running MariaDB service so that you can bring your cluster online.

Stop MariaDB on All Three Servers

When stopping the MariaDB service, it is important to execute this action on your servers in a specific order. This shutdown sequence ensures that the first node will be able to safely bootstrap the cluster when it starts up.

First, run the following command on the third node:

sudo systemctl stop mariadb

Next, stop the service on the second node:

sudo systemctl stop mariadb

Finally, stop the service on the first node:

sudo systemctl stop mariadb

systemctl doesn’t display the outcome of all service management commands, so to be sure you succeeded, use the following command on each of your servers:

sudo systemctl status mariadb

The last line will look something like the following:

Output. . . 
Apr 26 03:34:23 galera-node-01 systemd[1]: Stopped MariaDB 10.4.4 database server.

Once you’ve shut down mariadb on all of the servers, you’re ready to proceed.

Bring Up the First Node

To bring up the first node, you’ll need to use a special startup script. The way you’ve configured your cluster, each node that comes online tries to connect to at least one other node specified in its galera.cnf file to get its initial state. Without using the galera_new_cluster script that allows systemd to pass the --wsrep-new-cluster parameter, a normal systemctl start mariadb would fail because there are no nodes running for the first node to connect with.

sudo galera_new_cluster

This command will not display any output on successful execution. When this script succeeds, the node is registered as part of the cluster, and you can see it with the following command:

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"

You will see the following output indicating that there is one node in the cluster:

Output+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+

On the remaining nodes, you can start mariadb normally. They will search for any member of the cluster list that is online, so when they find one, they will join the cluster.

Bring Up the Second Node

Now you can bring up the second node. Start mariadb:

sudo systemctl start mariadb

No output will be displayed on successful execution. You will see your cluster size increase as each node comes online:

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"

You will see the following output indicating that the second node has joined the cluster and that there are two nodes in total.

Output
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 2     |
+--------------------+-------+

Bring Up the Third Node

It’s now time to bring up the third node. Start mariadb:

sudo systemctl start mariadb

Run the following command to find the cluster size:

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"

You will see the following output, which indicates that the third node has joined the cluster and that the total number of nodes in the cluster is three.

Output
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

At this point, the entire cluster is online and communicating successfully. Next, you can ensure the working setup by testing replication in the next section.

Step 8 — Testing Replication

You’ve gone through the steps up to this point so that your cluster can perform replication from any node to any other node, known as active-active replication. Follow the following steps to test and see if the replication is working as expected.

Write to the First Node

You’ll start by making database changes on your first node. The following commands will create a database called playground and a table inside of this database called equipment.

mysql -u root -p -e 'CREATE DATABASE playground;
CREATE TABLE playground.equipment ( id INT NOT NULL AUTO_INCREMENT, type VARCHAR(50), quant INT, color VARCHAR(25), PRIMARY KEY(id));
INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");'

In the previous command, the CREATE DATABASE statement creates a database named playground. The CREATE statement creates a table named equipment inside the playground database having an auto-incrementing identifier column called id and other columns. The type column, quant column, and color column are defined to store the type, quantity, and color of the equipment respectively. The INSERT statement inserts an entry of type slide, quantity 2, and color blue.

You now have one value in your table.

Read and Write on the Second Node

Next, look at the second node to verify that replication is working:

mysql -u root -p -e 'SELECT * FROM playground.equipment;'

If replication is working, the data you entered on the first node will be visible here on the second:

Output
+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+

From this same node, you can write data to the cluster:

mysql -u root -p -e 'INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");'

Read and Write on the Third Node

From the third node, you can read all of this data by querying the table again:

mysql -u root -p -e 'SELECT * FROM playground.equipment;'

You will see the following output showing the two rows:

Output
   +----+-------+-------+--------+
   | id | type  | quant | color  |
   +----+-------+-------+--------+
   |  1 | slide |     2 | blue   |
   |  2 | swing |    10 | yellow |
   +----+-------+-------+--------+

Again, you can add another value from this node:

mysql -u root -p -e 'INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");'

Read on the First Node

Back on the first node, you can verify that your data is available everywhere:

mysql -u root -p -e 'SELECT * FROM playground.equipment;'

You will see the following output, which indicates that the rows are available on the first node.

Output   +----+--------+-------+--------+
   | id | type   | quant | color  |
   +----+--------+-------+--------+
   |  1 | slide  |     2 | blue   |
   |  2 | swing  |    10 | yellow |
   |  3 | seesaw |     3 | green  |
   +----+--------+-------+--------+

You’ve verified successfully that you can write to all of the nodes and that replication is being performed properly.

Conclusion

At this point, you have a working three-node Galera test cluster configured. If you plan on using a Galera cluster in a production situation, it’s recommended that you begin with no fewer than five nodes.

Before production use, you may want to take a look at some of the other state snapshot transfer (SST) agents like XtraBackup, which allows you to set up new nodes very quickly and without large interruptions to your active nodes. This does not affect the actual replication, but is a concern when nodes are being initialized.

If you would like to continue learning about SQL databases, take a look at our How To Manage an SQL Database article.

Post/Tutorial Credit: https://www.digitalocean.com/community/tutorials/how-to-configure-a-galera-cluster-with-mariadb-on-centos-7-servers

Change mariadb/mysql Data Directory:

We are going to change default mariadb data directory /var/lib/mysql to /data/mysql

First stop mariadb service:

systemctl stop mariadb

Copy mysql directory to new path:

rsync -av /var/lib/mysql /data/

Edit galera config file to add new data path:

nano /etc/my.cnf.d/galera.cnf

[mysqld]

datadir = /data/mysql


socket  = /data/mysql/mysql.sock

.........

[client]

port=3306


socket=/data/mysql/mysql.sock

Adjust selinux policy for new directory:

semanage fcontext -a -t mysqld_db_t "/data/mysql(/.*)?"
restorecon -Rv /data/mysql

Start mariadb server:

systemctl start mariadb

Configure HAproxy Loadbalancer for the cluster

Step 2 - Install and Configure HAProxy

ssh haproxy1@192.168.1.135

Become root user and add the MariaDB server IP and hostname to the "/etc/hosts" file:

sudo su
vi /etc/hosts

HAProxy is available in the CentOS base repository, run this yum command to install it:

yum -y install haproxy

Then configure the log for HAProxy by editing the rsyslog configuration file:

vi /etc/rsyslog.conf

Uncomment the udp port:

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 51

Save the file and exit the editor.

Add the HAProxy configuration in rsyslog.d directory:

vi /etc/rsyslog.d/haproxy.conf

Paste configuration below:

local2.=info     /var/log/haproxy-access.log
local2.notice    /var/log/haproxy-info.log

Save the file and restart rsyslog:

systemctl restart rsyslog

Next, create a new HAProxy configuration file.

Go to the /etc/haproxy directory and backup the dafult haproxy configuration file.

cd /etc/haproxy/
mv haproxy.cfg haproxy.cfg.orig

Create new haproxy configuration file:

vi /etc/haproxy/haproxy.cfg

And paste the HAProxy configuration below:

global
        log 127.0.0.1   local2
        maxconn 1024
        user haproxy
        group haproxy
        daemon
        stats socket /var/run/haproxy.sock mode 600 level admin         # Make sock file for haproxy
 
defaults
        log     global
        mode    http
        option  tcplog
        option  dontlognull
        retries 3
        option  redispatch
        maxconn 1024
        timeout connect 5000ms
        timeout client 50000ms
        timeout server 50000ms
 
listen mariadb_cluster 0.0.0.0:3030
## MariaDB balance leastconn - the cluster listening on port 3030.
        mode tcp
        balance roundrobin
        option tcpka
        #balance leastconn
        #option httpchk
        server mariadb1 192.168.1.132:3306 check weight 1
        server mariadb2 192.168.1.133:3306 check weight 1
        server mariadb3 192.168.1.134:3306 check weight 1
listen stats 0.0.0.0:8080
## HAProxy stats web gui running on port 8080 - username and password: admin:admin.
        mode http
        stats enable
        stats uri /
        stats realm HAProxy\ Statistics
        stats auth admin:admin
        stats admin if TRUE

Port 3030 is the load balanced MariaDB port, we can access the databases on all MariaDB servers with load balancer IP and that port.

Port 9000 is the port for the web-gui, it allows monitoring of HAProxy from the browser.

Now start firewalld, open ports 9000 and 3030, and then reload it:

systemctl start firewalld
firewall-cmd --permanent --add-port=9000/tcp
firewall-cmd --permanent --add-port=3030/tcp
firewall-cmd --reload

Start HAProxy with the systemctl command:

systemctl start haproxy

Step 3 - Testing HAProxy and MariaDB

A. Replication testing

Login to the MariaDB server, access the MySQL shell and create a new database from mariadb1, then from mariadb2, and finally from mariadb3.

mysql -u root -p
create database this_mariadb1;  # Run this on mariadb1 server
create database this_mariadb2;  # Run this on mariadb2 server
create database this_mariadb3;  # Run this on mariadb3 server

Check the databases:

B. Access the MariaDB Server trough HAProxy

Now we access the MariaDB server cluster and databases trough the HAProxy IP on port 3030.

Before doing this test, enable remote access to the MariaDB server by creating a new user root with host "%".

Log into the MariaDB shell and create a new user "root" with password "aqwe123":

mysql -u root -p
GRANT ALL PRIVILEGES ON *.* TO root@'%' IDENTIFIED BY "aqwe123";

Next, access the 'mysql.user' database table trough the HAProxy server:

mysql -u root -p -h 192.168.1.135 -P 3030 -e "select Host, User, Password from mysql.user"

You can see the users of the database server by accessing the load balancer IP on port 3030. You can access the databases on the MySQL nodes by accessing the HAProxy IP on port 3030.

Another test of the server: the leastconn algorithm:

You can access the HAProxy monitoring server on port 9000, with username and password "howtoforge" to show the HAProxy web UI:

http://192.168.1.135:9000/stats

HAProxy has been installed successfully and you can see the MariaDB servers are monitored.

Post/Tutorial Credit: https://www.howtoforge.com/tutorial/how-to-setup-haproxy-as-load-balancer-for-mariadb-on-centos-7/

Setup Keycloak Server on Debian 11

noreply@blogger.com (Farhad) — Mon, 07 Nov 2022 07:51:00 +0000

apt-get -y update && apt-get -y upgrade

apt-get -y install default-jdk		

yum -y update && yum -y install java-11-openjdk-devel

cd /opt
wget https://github.com/keycloak/keycloak/releases/download/16.0.0/keycloak-16.0.0.tar.gz
tar -xvzf keycloak-16.0.0.tar.gz
mv keycloak-16.0.0.tar.gz keycloak

groupadd keycloak

useradd -r -g keycloak -d /opt/keycloak -s /sbin/nologin keycloak

chown -R keycloak: keycloak

chmod o+x /opt/keycloak/bin/

mkdir /etc/keycloak

cd /etc/keycloak
cp /opt/keycloak/docs/contrib/scripts/systemd/wildfly.conf /etc/keycloak/keycloak.conf

cp /opt/keycloak/docs/contrib/scripts/systemd/launch.sh /opt/keycloak/bin/

chown keycloak: /opt/keycloak/bin/launch.sh

vim /opt/keycloak/bin/launch.sh

WILDFLY_HOME="/opt/keycloak"

cp /opt/keycloak/docs/contrib/scripts/systemd/wildfly.service /etc/systemd/system/keycloak.service

vim /etc/systemd/system/keycloak.service

[Unit]

Description=Keycloak Application Server

After=network.target



[Service]

Type=idle

User=keycloak

Group=keycloak

ExecStart=/opt/keycloak/bin/standalone.sh -b 0.0.0.0

TimeoutStartSec=600

TimeoutStopSec=600



[Install]

WantedBy=multi-user.target

systemctl daemon-reload && systemctl enable keycloak && systemctl restart keycloak && systemctl status keycloak
##if service will not run use below commandchmod o+x /opt/keycloak/bin/standalone.sh

/opt/keycloak/bin/add-user-keycloak.sh -u admin -p YOURPASS -r master

systemctl restart keycloak

tail -f /opt/keycloak/standalone/log/server.log

http://<instance-public-ip-domain.com>:8080/auth/admin/

########### Disable SSL ############



/opt/keycloak/bin/kcadm.sh config credentials --server http://localhost:8080/auth --realm master --user admin

/opt/keycloak/bin/kcadm.sh update realms/master -s sslRequired=NONE

upstream mywebapp1 {
server 127.0.0.1:8080;
}
server {
    listen 80;
    listen 443 ssl http2;
    server_name *.bd;
    ssl_certificate /cert/2019/nothi.pem;
    ssl_certificate_key /cert/2019/nothi.key;
    ssl_session_cache shared:SSL:120m;
    ssl_session_timeout 60m;
    ssl_prefer_server_ciphers on;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;
    add_header Strict-Transport-Security "max-age=31536000";
    location / {
        proxy_pass http://mywebapp1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Using Fail2Ban to prevent/limit bot attack to wordpress wp-login.php [Centos7]

noreply@blogger.com (Farhad) — Mon, 22 Aug 2022 07:46:00 +0000

This article demonstrates how to use Fail2Ban to block IP addresses attempting to compromise a WordPress instance via the login process. In this walk-through, we’re using CentOS 7 and FirewallD. Just be aware that if you’re using a caching service like CloudFlare, you can’t use this method because you’ll block the cache and not the source of the traffic.

Install Fail2Ban:

yum install fail2ban fail2ban-firewalld

Edit the “/etc/fail2ban/jail.conf” file. Add the following chunk to the bottom of that file. Notice the log file to be monitored. You can either specify it exactly or use a wild-card:

[apache-wordpress-login]
enabled = true
action = iptables-multiport[name=wordpress, port="http,https", protocol=tcp]
port = http,https
filter = apache-wordpress-login
logpath = /var/log/httpd/*_log
bantime = 36000
findtime = 600
maxretry = 1

And modify the “ignoreip” line to include the IP that you’re coming from (so you don’t get kicked out):

ignoreip = 127.0.0.1/8 ::1 my.ip.address

And set the following to ensure FirewallD is assumed:

#banaction = iptables-multiport
banaction = firewallcmd-ipset

Create the file “/etc/fail2ban/filter.d/apache-wordpress-login.conf” and enter the following content:

[Definition]
mode = normal
failregex = ^<HOST> -.*"POST.*wp-login.php

#Note: If you want to add more filter you can use like below:
[Definition]
mode = normal
failregex = ^<HOST> -.*"POST.*wp-login.php
            ^<HOST> -.*"POST.*xmlrpc.php
            ......................

Enable and Start Fail2Ban:

systemctl enable fail2ban
systemctl start fail2ban

Check the status of Fail2Ban blocking hosts:

fail2ban-client status apache-wordpress-login
firewall-cmd --list-all
iptables -L -n
tail -f /var/log/fail2ban.log

Post Credit: https://www.agix.com.au/using-fail2ban-to-protect-wordpress-logins-centos/

Daily mysql databse backup with datetime stamp with cronjob

noreply@blogger.com (Farhad) — Wed, 13 Oct 2021 15:23:00 +0000

Creating MySQL Backup Script

First we need to create a script with below content called “daily-mysql-backup.sh” and save it on your system. Please change the below value as per your requirements. for root user "--no-tablespaces" is not required, for remote host we need to add extra parameter -h192.168.5.10 after -p parameter.

#!/bin/bash

USER="dbuser"

PASS="dbpass"

mysqldump -u$USER -p$PASS database_name --no-tablespaces | gzip -c > /home/jafar/db_backups/database_name_$(date "+%b_%d_%Y_%H_%M_%S").sql.gz

Now we need to set the cronjob for the daily backup, we will run the backup at 2AM every night. Use the below command and add the corn job to the file and save the crontab reload or restart the cron service with last command

crontab -e

00 02 * * * /bash_scripts/daily-mysql-backup.sh

systemctl reload cron ##for ubuntu based system

systemctl reload crond ##for redhat based system

Specific NodeJs version install with NVM

noreply@blogger.com (Farhad) — Thu, 02 Apr 2020 10:39:00 +0000

Node.js is an opensource cross-platform JavaScript run-time environment for server-side execution of JavaScript code. It’s built on Chrome’s JavaScript engine so it can be used to build different types of server-side application. npm is the very popular and default package manager for Node.js with large number of packages. In this tutorial, we will learn how to install Node.js and npm on Debian 9.

Install Node.js and npm on Debian

There are multiple ways to install Node.js and npm on your Debian 9 systems. You can follow any of following to install:

Install Node.js from NodeSource Repository

NodeSource provides a repository containing latest version of Node.js and npm. It’s very simple to install Node.js and npm from NodeSource.

At first, you need to add NodeSource repository on your system using following curl command:

curl -sL https://deb.nodesource.com/setup_10.x | sudo bash -

NOTE : The latest LTS version of Node.js is 10.x if you want to install 8.x version then just replace setup_10.x with setup_8.x

After that, install Node.js and npm with the following command:

sudo apt install nodejs

Verify installation of Node.js and npm running below command:

node --version

Output
v9.10.1

npm --version

Output
5.6.0

Install Node.js and npm using nvm

NVM (Node Version Manager) script is used to manage multiple Node.js versions. You can install or uninstall specific Node.js versions using NVM.

At first, we need to download nvm install script on your system using below command:

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash

It will copy the nvm repository from Github to the ~/.nvm directory and add the nvm path to your Bash profile.

=> Close and reopen your terminal to start using nvm or run the following to use it now:
 export NVM_DIR="$HOME/.nvm"
 [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"  # This loads nvm
 [ -s "$NVM_DIR/bash_completion" ] && . "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

As you can see in output, it is suggesting to either open new shell session or run the commands to add the path to the nvm script to your current session.

You can verify that nvm is installed properly by typing:

nvm --version

Output
0.33.11

Now you have nvm installed on your Debian system. You can install the latest available version of Node.js using below command:

nvm install node

It will show output as below:

Downloading and installing node v12.0.0…
Downloading https://nodejs.org/dist/v12.0.0/node-v12.0.0-linux-x64.tar.xz…
################################################################## 100.0%
Computing checksum with sha256sum
Checksums matched!
Now using node v12.0.0 (npm v6.9.0)
Creating default alias: default -> node (-> v12.0.0)

Once the installation is finished you can check the version of Node.js by typing :

node --version

Output
v12.0.0

Next, We will install two more versions of Node.js. To do so type following:

nvm install --lts
nvm install 9.10.1

Once the both of above versions are installed we can view list using below command:

nvm ls

->      v9.10.1
        v10.15.3
         v12.0.0
 default -> node (-> v12.0.0)
 node -> stable (-> v12.0.0) (default)
 stable -> 12.0 (-> v12.0.0) (default)
 iojs -> N/A (default)
 lts/* -> lts/dubnium (-> v10.15.3)
 lts/argon -> v4.9.1 (-> N/A)
 lts/boron -> v6.17.1 (-> N/A)
 lts/carbon -> v8.16.0 (-> N/A)
 lts/dubnium -> v10.15.3

In output version with arrow is used for the current shell session. Default version is set to v12.0.0 and it will be used when you open new shell sessions.

You can change the current default version of Node.js by using the following command:

nvm use 10.15.3

Now verify it by typing:

nvm current

Output
v10.15.3

You also can set set version 10.15.3 as the default Node.js version using below command:

nvm alias default 10.15.3

You can uninstall a Node.js version type following command:

nvm uninstall 9.10.1

Uninstall Node.js and npm

To uninstall Node.js use following command:

sudo apt remove nodejs npm
sudo apt autoremove

To uninstall node.js version using nvm type following command:

nvm uninstall 10.15.3

Conclusion

Finally, you have learned how to install nodejs and npm on your Debian system with different methods. At the end of tutorial you also learned how to uninstall it.

Original post: https://tecnstuff.net/how-to-install-node-js-on-debian-9/

Install wkhtmltopdf from source

noreply@blogger.com (Farhad) — Wed, 12 Feb 2020 07:02:00 +0000

Install wkhtmltopdf on Debian 8, 9

Reference: https://gist.github.com/fedir/48caf91c02197ecb68c22a70555f6f0e

Raw

 wkhtmltopdf@Debian8.sh

apt-get update
aptitude install xfonts-base xfonts-75dpi fontconfig xvfb
mkdir ~/src/wkhtmltopdf -p
cd ~/src/wkhtmltopdf
wget https://bitbucket.org/wkhtmltopdf/wkhtmltopdf/downloads/wkhtmltox-0.13.0-alpha-7b36694_linux-jessie-amd64.deb
dpkg -i wkhtmltox-0.13.0-alpha-7b36694_linux-jessie-amd64.deb
echo 'xvfb-run --server-args="-screen 0, 1024x768x24" /usr/local/bin/wkhtmltopdf $*' > /usr/bin/wkhtmltopdf.sh
chmod a+rx /usr/bin/wkhtmltopdf.sh
ln -s /usr/bin/wkhtmltopdf.sh /usr/local/sbin/wkhtmltopdf
/usr/local/sbin/wkhtmltopdf https://www.google.fr output.pdf

Raw

 wkhtmltopdf@Debian9.sh

apt-get update
apt-get install wkhtmltopdf xvfb xauth xfonts-base xfonts-75dpi fontconfig 
echo 'xvfb-run --server-args="-screen 0, 1024x768x24" /usr/bin/wkhtmltopdf $*' > /usr/bin/wkhtmltopdf.sh
chmod a+rx /usr/bin/wkhtmltopdf.sh
ln -s /usr/bin/wkhtmltopdf.sh /usr/local/sbin/wkhtmltopdf
/usr/local/sbin/wkhtmltopdf https://www.google.fr output.pdf

Prevent SSH Brute Force Attack by Automatically Blacklisted

noreply@blogger.com (Farhad) — Wed, 01 Aug 2018 08:50:00 +0000

Automated Solution for Centos/RHEL to Block Bad Actors

Here's a script for Centos to check ssh failed logins for both invalid user accounts and bad passwords for valid accounts. If the source IP has hit us more than 3 times and is not already on the deny list, it gets added to the deny list. I run this every 15 minutes from root's crontab. I've also disallowed root logins via ssh, so the combination keeps things fairly quiet.

     #/bin/bash
     # Save a copy of the existing hosts.deny file for safety
     cp /etc/hosts.deny /etc/hosts.deny.bak
     # Get a list of the offending IP addresses and process them
     for z in `grep "Invalid\|Failed" /var/log/secure | awk '{ print $NF }' | sort | uniq`
     do
     # Get the number of times this IP hit us
     hits=`grep "Invalid\|Failed" /var/log/secure* | grep $z | wc -l`
     # Check whether this IP is already blocked
     blocked=`grep $z /etc/hosts.deny | wc -l`
     # If they hit us more than 3 times and are not already on the deny list
     # add them to the deny list
     if [ $hits -gt 3 -a $blocked -eq 0 ]
     then
          echo "sshd : $z" >> /etc/hosts.deny
     fi
     done

Another Example:

for z in `grep Invalid /var/log/auth.log | awk '{ print $NF }' | sort | uniq`
do
  count1=`grep $z /etc/hosts.deny | wc -l`
  count2=`grep Invalid /var/log/auth.log | grep $z | wc -l`
  if [ $count1 -eq 0 -a $count2 -gt 10 ] ; then
    current=`egrep "^ssh" /etc/hosts.deny | sed 's/sshd[ :,]*//'`
    sudo cp /etc/hosts.deny.bak /etc/hosts.deny
    sudo chmod 666 /etc/hosts.deny
    if [ $current ] ; then
      echo "sshd : $current , $z" >> /etc/hosts.deny
    else
      echo "sshd : $z" >> /etc/hosts.deny
    fi
    sudo chmod 644 /etc/hosts.deny
  fi
done

Post Credit: https://serverfault.com/questions/594746/how-to-stop-prevent-ssh-bruteforce

Bandwidth Limiting Big Files Download - Mikrotik

noreply@blogger.com (Farhad) — Wed, 18 Jul 2018 17:52:00 +0000

Here is one of my queues with burst, setup using Winbox.

All settings are on the General Tab. Settings are given as tx/rx (upload/download).

Name - 2.201/32
Target Address - 192.168.2.201/32
Limit At - 65536/131072
Max Limit - 262144/524288
Burst Limit - 393216/786432
Burst Threshold - 262144/524288
Burst Time - 90/180

This is a Simple queue for the user at IP 192.168.2.201. He is given a basic speed of 64k upload and 128k download. According to the MT manual, this is a guaranteed minimum speed, provided enough bandwidth is available. His maximum sustained speed is 256k upload and 512k download.

His speed is allowed to burst as high as 384k upload and 768k download. If his speed goes above the threshold (256/512) and stays there, the burst timer starts. After the allowed time, 90sec for upload and 180sec for download, his speed is throttled back from the burst limit (384/768) to the max limit (256/512) and held there until the traffic flow stops. When the flow stops, the timer resets, and the process starts over.

The variables are adjustable to suit different needs and situations. If you provide at least 75 seconds on the timer, most speed tests and small file transfers will complete in that time and show fast speeds. If they start a large file download, it will complete part of it fairly quick and then slow down for the remainder of the transfer so they are not hogging the pipe.

Reference: https://forum.mikrotik.com/viewtopic.php?t=2138

WSO2Torial: Setting up WSO2 with a valid SSL certificate

noreply@blogger.com (Farhad) — Thu, 05 Jul 2018 16:36:00 +0000

WSO2 products can be downloaded from the WSO2 website, installed in a matter of seconds after which you can try out the software. No fees, no contracts and …. no lawyers.

What you’ll find when you start up any WSO2 product is that the browser will balk on the certificate that is used to encrypt the connection. This is a so called self-signed certificate and is deemed to be less secure then one from a Certificate authority.

How do Certificates work?

Without going into too much detail, certificates work using a trust mechanism. Certificates are issued by a so called Certificate Authority like the companies Comodo or Symantec. A certificate issued by them should be trusted since the trust relationship with CA’s is beyond discussion. The certificate issued guarantees that the site is indeed who it claims to be.

Certificates in this sense are used to encrypt the secure https traffic to and from your WSO2 products. To set up HTTPS you will need a valid certificate to enable the WSO2 product to encrypt the connection.

For this tutorial I've used a wildcard certificate signed by a (trusted) Certificate authority. This certificate will be used instead of the self-signed WSO2 certificates in the keystore . These are great for testing purposes but in a production environment you will of course want to change this keystore with a different one. And you also get rid of these pesky messages about security inherent with self signed certificates.

Mind you that certificates cost money since a service (in this case trust) is offered. There are some organizations that offer free 90 days certificates if you want to try it out and not directly shell out money for a full certificate. Keep in mind that you will need to offer proof of ownership or control over the website that you want the certificate for. For more information we direct you to the internet.

We assume that you have a working WSO2 product, e.g. an WSO2 ESB. Before we start we will need to collect a few things.

A valid certificate, usually acquired from your company’s system administrator
The Certificate private key, usually acquired from your company’s system administrator
The intermediary and root certificates provided by the trust company who signed the valid certificate.

These can be downloaded from the company’s website (In this case I've used a comodo certificate https://support.comodo.com/index.php?/Default/Knowledgebase/List/Index/108/sha-2)

To find out which ones you need you will have to open the valid certificate and open the below window.

This is the tab you need to see the certificate chain, you can see that the clients wildcard certificate is the one currently selected.

Above the current certificate there are two other certificates listed, these are the intermediary certificates within the certificate chain.

When selected they will show the names of the intermediary certificates you’ll need:

Comodo RSA Organization Validation Secure Server ca certificate
Comodo RSA Certification Authority certificate

In case of the root certificate this one is not listed and is most likely already embedded in the system you're using, if you're not sure it shouldn’t break anything to add this one too.
Add Trust External ca root certificate

Here you can see the signed wildcard certificate (*.domain.nl) and the two intermediary certificates in the chain. When you open the intermediaries you can find the exact name of the certificate you will need to find.

So the intermediaries we need are the COMODO RSA Certification authority cert and the Comodo Rsa Organization Validation Secure Server ca.

Creating and configuring a new keystore

Creating a new keystore with a trusted key takes the following steps:

Creating a PKCS12/PFX file
Creating the Keystore
Export a public key from the JKS file
Adding the keystore and public key to the product
- Adding the public key to the Public truststore
- Configuring the product to use the new keystore
Adding the intermediary certificates to the keystore.
Done!

We will describe these steps in more detail below.

Before we can create a keystore we will have to create a .pfx file with the collected certificates and key.

Step 1 - Creating a PKCS12/PFX File

First you must export certificates to the PKCS12/PFX format. Use strong passwords whenever required.

We used an openssl prompt for this part of the process, you can open it in command line by typing "openssl".

To generate a correct PFX file you will need to use the following command, if correctly executed it will ask for a password twice, don't forget whatever you decide to use as a password as you will need it later!

openssl pkcs12 -export -in (customer valid certificate file).crt -inkey (customer valid certficate file private key).key -name "alias for your pfx" -certfile (additional certificate intermediary1) -out (pfx keystore name).pfx

This will result in a valid pfx file.

Step 2 - Creating the keystore
Now we will Convert the PKCS12/PFX file to a Java keystore using the following command:

keytool -importkeystore -srckeystore (pkcs12/pfx file name).pfx -srcstoretype pkcs12 -destkeystore (Keystore file name).jks -deststoretype JKS

For this command you will need a valid JDK installation, keytool comes with the JDK. It can be found in the /bin directory of the JDK.

If your command line cannot find keytool when you try to use it your PATH environment variable might not be set. Edit the PATH environment variable on your computer and add the location of the jdk bin folder to it. Once this is configured you should be able to use keytool from any directory on the computer. Once the command is executed you will have a valid Keystore!

Step 3 - Export a public key from your JKS file

Aside from the keystore there is a "Public truststore" inside the WSO2 product, we will need to add the public key of our keystore to this truststore.

Since we don't have a public key yet we will have to export this one from the Keystore.

keytool -export -alias "certificate alias" -keystore (mykeystore.jks) -file (public key name).pem

Make sure the alias is the same as the one you used for your pfx file.

Step 4 - Adding the keystore and public key to the product

Before we can configure the keystore and public key for WSO2 product we have to place the files inside the /repository/resources/security folder.

Once the files are in position we can configure the product to use our newly created files.

Step 4.1 - Adding the public key to the Public truststore

The public truststore in the /repository/resources/security/ folder is called "client-truststore.jks", we will add the public key to this truststore with the below command.

keytool -import -alias (certificate alias) -file (public key name).pem -keystore client-truststore.jks -storepass wso2carbon

Note: the default password for the client-truststore.jks is "wso2carbon".

Step 4.2 - Configuring the product to use the new keystore

Inside each WSO2 product there are many different files that refer to the default keystore, if you want to replace it with the new one you will have to change the entry in all of the relevant places.

The most important file to configure is the primary keystore entry in the /repository/conf/carbon.xml file, if you don't want to edit this entry you can also manually add an extra keystore entry.

The entry will look like this:

${carbon.home}/resources/security/
wso2carbon.jks
JKS
wso2carbon
wso2carbon
wso2carbon

#####

    JKS
    wso2carbon
    wso2carbon
    wso2carbon

Change it to something like this:

    JKS
    wso2carbon
    wso2carbon
    wso2carbon

#####################################################################

Change it to something like this:



    ${carbon.home}/resources/security/
    JKS

Note that the password is stored in plaintext. If you want to store a more secure placeholder with an encrypted value, use SecureVault. For more information on this subject I will refer you to my colleague’s blog: https://www.yenlo.com/blog/wso2torial-encrypt-passwords-using-secure-vault

The easiest way to find all the other entries of the default keystore is to use the "grep -nr ".jks" in the /repository/conf/ folder, this will list all the relevant entries and their files.

You will get something like below. Now you can open each of the files you find and change the relevant keystore entries.

/axis2/axis2.xml:260:                repository/resources/security/wso2carbon.jks
./axis2/axis2.xml:431:                repository/resources/security/wso2carbon.jks
./carbon.xml:316:            ${carbon.home}/repository/resources/security/wso2carbon.jks
./carbon.xml:332:            ${carbon.home}/repository/resources/security/wso2carbon.jks
./identity.xml:180:             ${carbon.home}/repository/resources/security/wso2carbon.jks
./security/secret-conf.properties:21:#keystore.identity.location=repository/resources/security/wso2carbon.jks

Once you've replaced these entries, restart the server.

Step 5 - Adding the intermediary certificates to the keystore.

Now that we've correctly configured the keystore we can look it up in the carbon console.

Under the Main tab there is a button called "Keystores" here you would originally see the "wso2carbon.jks" now you should see your own keystore.

If this is not the case, make sure you correctly configured the keystore entry in the carbon.xml.

It should look like this with your keystore name listed.

Now we just need to add the intermediary and (optionally) the root certificate to the keystore.

Click the Import cert button and do this for the intermediary certificates. It will end up looking something like this:

Step 6 - Done!

Restart the server and go to the carbon console, in your browser next to your URL it will show whether the connection is valid HTTPS.

If it still shows the website as unsafe in your browser you can get extra details about the problem by clicking on the notification in your browser.

If you can't find enough information through there you can also try one of many SSL checker web tools like https://www.ssllabs.com/ssltest/.

Note: Don't forget that if you go straight to the IP address in your browser and not through a DNS address it will also say that the HTTPS is not correct. This is because in our case the certificate used was for *.domain.nl so the browser only rates the website as secure if you go through a variation of *.domain.nl.

If you have any questions about this blogpost contact us via the comments section of this blog. View also our WSO2 Tutorials, webinars or white papers for more technical information. Need support? We do deliver WSO2 Product Support, WSO2 Development Support, WSO2 Operational Support and WSO2 Training Programs.

Tutorial Credit: https://www.yenlo.com/blog/setting-up-wso2-with-a-valid-certificate

Give permission to a SSH user only to a specific directory and block terminal access !!

noreply@blogger.com (Farhad) — Mon, 16 Apr 2018 07:41:00 +0000

How do I restrict the user to only be able to do anything within that folder? (ie: that folder is the user's root and they cannot view/edit anything higher in the directory tree)

Step-1: adding a new group

sudo addgroup sftptsl

Step-2: Create the chroot directory

sudo mkdir /var/www/html/user-dir/

sudo chmod g+rx /var/www/html/user-dir/

Step-3: Create the group-writable directory

sudo mkdir -p /var/www/html/user-dir/working-dir1/

sudo chmod g+rwx /var/www/html/user-dir/working-dir1/

Step-4: Give them both to the new group.

sudo chgrp -R sftptsl /var/www/html/user-dir/

Step-5: create an user and asign to this group

sudo adduser --ingroup sftptsl sftpuser

## group change

You can also assign an existing user to the group

usermod -g primarygroupname username

usermod -G secondarygroupname username

-g (primary group assigned to the users)

-G (Other groups the user belongs to)

Step-6: Open the SSH configuration file from "/etc/ssh/sshd_config", add the below text end of the file

Match Group sftptsl

# Force the connection to use SFTP and chroot to the required directory.

ForceCommand internal-sftp

ChrootDirectory /var/www/html/user-dir/

# Disable tunneling, authentication agent, TCP and X11 forwarding.

PermitTunnel no

AllowAgentForwarding no

AllowTcpForwarding no

X11Forwarding no

Step-7: Check it is working or not by using filezilla or any remote file browser.

SWAP: Allocate swap space in Centos7

noreply@blogger.com (Farhad) — Thu, 15 Mar 2018 15:51:00 +0000

Introduction

One of the easiest ways to make your server more responsive, and guard against out-of-memory errors in your application, is to add some swap space. Swap is an area on a storage drive where the operating system can temporarily store data that it can no longer hold in memory.

This gives you the ability to increase the amount of information that your server can keep in its working memory, with some caveats. Reading from and writing to swap is slower than using memory, but it can provide a good safety net for when your server is low on memory.

Without swap, a server that runs out of memory may start killing applications to free up memory, or even crash. This can cause you to lose unsaved data or experience downtime. To ensure reliable data access, some applications require swap to function.

In this guide, we will cover how to create and enable a swap file on a CentOS 7 server.

Note

Although swap is generally recommended for systems utilizing traditional spinning hard drives, using swap with SSDs can cause issues with hardware degradation over time. Due to this consideration, we do not recommend enabling swap on DigitalOcean or any other provider that utilizes SSD storage. Doing so can impact the reliability of the underlying hardware for you and your neighbors.

If you need to improve the performance of your server, we recommend upgrading your Droplet. This will lead to better results in general and will decrease the likelihood of contributing to hardware issues that can affect your service.

Prerequisites

Before you begin with this guide, there are a few steps that need to be completed first.

You will need a CentOS 7 server installed and configured with a non-root user that has sudo privileges. If you haven't done this yet, you can run through steps 1-4 in the CentOS 7 initial server setup guide to create this account.

Once you have your non-root user, you can use it to SSH into your CentOS server and continue with the installation of your swap file.

Check the System for Swap Information

Before we begin, we should take a look at our server's storage to see if we already have some swap space available. While we can have multiple swap files or swap partitions, one should generally be enough.

We can see if the system has any configured swap by using swapon, a general-purpose swap utility. With the -s flag, swapon will display a summary of swap usage and availability on our storage device:

swapon -s

If nothing is returned by the command, then the summary was empty and no swap file exists.

Another way of checking for swap space is with the free utility, which shows us the system's overall memory usage. We can see our current memory and swap usage (in megabytes) by typing:

free -m

             total       used       free     shared    buffers     cached
Mem:          3953        315       3637          8         11        107
-/+ buffers/cache:        196       3756
Swap:            0          0       4095

As you can see, our total swap space in the system is 0. This matches what we saw with swapon.

Check Available Storage Space

The typical way of allocating space for swap is to use a separate partition that is dedicated to the task. However, altering the partition scheme is not always possible due to hardware or software constraints. Fortunately, we can just as easily create a swap file that resides on an existing partition.

Before we do this, we should be aware of our current drive usage. We can get this information by typing:

df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        59G  1.5G   55G   3% /
devtmpfs        2.0G     0  2.0G   0% /dev
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           2.0G  8.3M  2.0G   1% /run
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup

Note: the -h flag simply tells dh to output drive information in a human-friendly reading format. For example, instead of outputting the raw number of memory blocks in a partition, df -h will tell us the space usage and availability in M (for megabytes) or G (for gigabytes).

As you can see on the first line, our storage partition has 59 gigabytes available, so we have quite a bit of space to work with. Keep in mind that this is on a fresh, medium-sized VPS instance, so your actual usage might be very different.

Although there are many opinions about the appropriate size of a swap space, it really depends on your application requirements and your personal preferences. Generally, an amount equal to or double the amount of memory on your system is a good starting point.

Since my system has 4 gigabytes of memory, and doubling that would take a larger chunk from my storage space than I am willing to part with, I will create a swap space of 4 gigabytes to match my system's memory.

Create a Swap File

Now that we know our available storage space, we can go about creating a swap file within our filesystem. We will create a file called swapfile in our root (/) directory, though you can name the file something else if you prefer. The file must allocate the amount of space that we want for our swap file.

The fastest and easiest way to create a swap file is by using fallocate or dd. This command creates a file of a preallocated size instantly. We can create a 4 gigabyte file by typing:

sudo fallocate -l 4G /swapfile

if fallocate fails then try dd

sudo dd if=/dev/zero of=/swapfile count=4096 bs=1MiB

After entering your password to authorize sudo privileges, the swap file will be created almost instantly, and the prompt will be returned to you. We can verify that the correct amount of space was reserved for swap by using ls:

ls -lh /swapfile

-rw-r--r-- 1 root root 4.0G Oct 30 11:00 /swapfile

As you can see, our swap file was created with the correct amount of space set aside.

Enable a Swap File

Right now, our file is created, but our system does not know that this is supposed to be used for swap. We need to tell our system to format this file as swap and then enable it.

Before we do that, we should adjust the permissions on our swap file so that it isn't readable by anyone besides the root account. Allowing other users to read or write to this file would be a huge security risk. We can lock down the permissions with chmod:

sudo chmod 600 /swapfile

This will restrict both read and write permissions to the root account only. We can verify that the swap file has the correct permissions by using ls -lh again:

ls -lh /swapfile

-rw------- 1 root root 4.0G Oct 30 11:00 /swapfile

Now that our swap file is more secure, we can tell our system to set up the swap space for use by typing:

sudo mkswap /swapfile

Setting up swapspace version 1, size = 4194300 KiB
no label, UUID=b99230bb-21af-47bc-8c37-de41129c39bf

Our swap file is now ready to be used as a swap space. We can begin using it by typing:

sudo swapon /swapfile

To verify that the procedure was successful, we can check whether our system reports swap space now:

swapon -s

Filename                Type        Size    Used    Priority
/swapfile               file        4194300 0     -1

This output confirms that we have a new swap file. We can use the free utility again to corroborate our findings:

free -m

             total       used       free     shared    buffers     cached
Mem:          3953        315       3637          8         11        107
-/+ buffers/cache:        196       3756
Swap:         4095          0       4095

Our swap has been set up successfully, and our operating system will begin to use it as needed.

Make the Swap File Permanent

Our swap file is enabled at the moment, but when we reboot, the server will not automatically enable the file for use. We can change that by modifying the fstab file, which is a table that manages filesystems and partitions.

Edit the file with sudo privileges in your text editor:

sudo nano /etc/fstab

At the bottom of the file, you need to add a line that will tell the operating system to automatically use the swap file that you created:

/swapfile   swap    swap    sw  0   0

When you are finished adding the line, you can save and close the file. The server will check this file on each bootup, so the swap file will be ready for use from now on.

Tweak Your Swap Settings (Optional)

There are a few options that you can configure that will have an impact on your system's performance when dealing with swap. These configurations are optional in most cases, and the changes that you make will depend on your application needs and your personal preference.

Swappiness

The swappiness parameter determines how often your system swaps data out of memory to the swap space. This is a value between 0 and 100 that represents the percentage of memory usage that will trigger the use of swap.

With values close to zero, the system will not swap data to the drive unless absolutely necessary. Remember, interactions with the swap file are "expensive" in that they are a lot slower than interactions with memory, and this difference in read and write speed can cause a significant reduction in an application's performance. Telling the system not to rely on the swap as much will generally make your system faster.

Values that are closer to 100 will try to put more data into swap in an effort to keep more memory free. Depending on your applications' memory profile, or what you are using your server for, this might be the better choice in some cases.

We can see the current swappiness value by reading the swappiness configuration file:

cat /proc/sys/vm/swappiness

CentOS 7 defaults to a swappiness setting of 30, which is a fair middle ground for most desktops and local servers. For a VPS system, we'd probably want to move it closer to 0.

We can set the swappiness to a different value by using the sysctl command. For instance, to set the swappiness to 10, we could type:

sudo sysctl vm.swappiness=10

vm.swappiness = 10

This setting will persist until the next reboot. To make the setting persist between reboots, we can add the outputted line to our sysctl configuration file:

sudo nano /etc/sysctl.conf

Add your swappiness setting to the bottom of the file:

vm.swappiness = 10

When you are finished adding the line, you can save and close the file. The server will now automatically set the swappiness to the value you declared on each bootup.

Cache Pressure

Another related value that you might want to modify is the vfs_cache_pressure. This setting affects the storage of special filesystem metadata entries. Constantly reading and refreshing this information is generally very costly, so storing it on the cache for longer is excellent for your system's performance.

You can see the current value of this cache pressure by querying the proc filesystem again:

cat /proc/sys/vm/vfs_cache_pressure

As it is currently configured, our system removes inode information from the cache far too quickly. We can set this to a more conservative setting, like 50, by using sysctl:

sudo sysctl vm.vfs_cache_pressure=50

vm.vfs_cache_pressure = 50

Again, this is only valid for our current session. We can change that by adding it to our configuration file, like we did with our swappiness setting:

sudo nano /etc/sysctl.conf

At the bottom, add the line that specifies your new value:

vm.vfs_cache_pressure = 50

When you are finished adding the line, you can save and close the file. The server will now automatically set the cache pressure to the value you declared on each bootup.

Conclusion

By following the steps in this guide, you will have given your server some breathing room in terms of memory usage. Swap space is incredibly useful in avoiding some common problems.

If you are running into OOM (out of memory) errors, or if you find that your system is unable to use the applications that you need, the best solution is to optimize your application configurations or upgrade your server. However, configuring swap space can give you more flexibility and can help buy you time on a less powerful server.

Credit: https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-centos-7

Initial Server Setup with CentOS 7

noreply@blogger.com (Farhad) — Sun, 21 Jan 2018 08:54:00 +0000

Introduction

When you first create a new server, there are a few configuration steps that you should take early on as part of the basic setup. This will increase the security and usability of your server and will give you a solid foundation for subsequent actions.

To log into your server, you will need to know your server's public IP address and the password for the "root" user's account. If you have not already logged into your server, you may want to follow the first tutorial in this series, How to Connect to Your Droplet with SSH, which covers this process in detail.

If you are not already connected to your server, go ahead and log in as the root user using the following command (substitute the highlighted word with your server's public IP address):


ssh root@SERVER_IP_ADDRESS

Complete the login process by accepting the warning about host authenticity, if it appears, then providing your root authentication (password or private key). If it is your first time logging into the server, with a password, you will also be prompted to change the root password.

About Root

The root user is the administrative user in a Linux environment that has very broad privileges. Because of the heightened privileges of the root account, you are actually discouraged from using it on a regular basis. This is because part of the power inherent with the root account is the ability to make very destructive changes, even by accident.

The next step is to set up an alternative user account with a reduced scope of influence for day-to-day work. We'll teach you how to gain increased privileges during the times when you need them.

Step Two — Create a New User

Once you are logged in as root, we're prepared to add the new user account that we will use to log in from now on.

This example creates a new user called "demo", but you should replace it with a user name that you like:


adduser demo

Next, assign a password to the new user (again, substitute "demo" with the user that you just created):


passwd demo

Enter a strong password, and repeat it again to verify it.

Step Three — Root Privileges

Now, we have a new user account with regular account privileges. However, we may sometimes need to do administrative tasks.

To avoid having to log out of our normal user and log back in as the root account, we can set up what is known as "super user" or root privileges for our normal account. This will allow our normal user to run commands with administrative privileges by putting the word sudo before each command.

To add these privileges to our new user, we need to add the new user to the "wheel" group. By default, on CentOS 7, users who belong to the "wheel" group are allowed to use the sudo command.

As root, run this command to add your new user to the wheel group (substitute the highlighted word with your new user):


gpasswd -a demo wheel

Now your user can run commands with super user privileges! For more information about how this works, check out our sudoers tutorial.

Step Four — Add Public Key Authentication (Recommended)

The next step in securing your server is to set up public key authentication for your new user. Setting this up will increase the security of your server by requiring a private SSH key to log in.

Generate a Key Pair

If you do not already have an SSH key pair, which consists of a public and private key, you need to generate one. If you already have a key that you want to use, skip to the Copy the Public Key step.

To generate a new key pair, enter the following command at the terminal of your local machine:


ssh-keygen

Assuming your local user is called "localuser", you will see output that looks like the following:


ssh-keygen output
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/localuser/.ssh/id_rsa):

Hit return to accept this file name and path (or enter a new name).

Next, you will be prompted for a passphrase to secure the key with. You may either enter a passphrase or leave the passphrase blank.

Note: If you leave the passphrase blank, you will be able to use the private key for authentication without entering a passphrase. If you enter a passphrase, you will need both the private key and the passphrase to log in. Securing your keys with passphrases is more secure, but both methods have their uses and are more secure than basic password authentication.

This generates a private key, id_rsa, and a public key, id_rsa.pub, in the .ssh directory of the localuser's home directory. Remember that the private key should not be shared with anyone who should not have access to your servers!

Copy the Public Key

After generating an SSH key pair, you will want to copy your public key to your new server. We will cover two easy ways to do this.

Note: The ssh-copy-id method will not work on DigitalOcean if an SSH key was selected during Droplet creation. This is because DigitalOcean disables password authentication if an SSH key is present, and the ssh-copy-id relies on password authentication to copy the key.

If you are using DigitalOcean and selected an SSH key during Droplet creation, use option 2 instead.

Option 1: Use ssh-copy-id

If your local machine has the ssh-copy-id script installed, you can use it to install your public key to any user that you have login credentials for.

Run the ssh-copy-id script by specifying the user and IP address of the server that you want to install the key on, like this:


ssh-copy-id demo@SERVER_IP_ADDRESS

After providing your password at the prompt, your public key will be added to the remote user's .ssh/authorized_keys file. The corresponding private key can now be used to log into the server.

Option 2: Manually Install the Key

Assuming you generated an SSH key pair using the previous step, use the following command at the terminal of your local machine to print your public key (id_rsa.pub):


cat ~/.ssh/id_rsa.pub

This should print your public SSH key, which should look something like the following:


id_rsa.pub contents
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBGTO0tsVejssuaYR5R3Y/i73SppJAhme1dH7W2c47d4gOqB4izP0+fRLfvbz/tnXFz4iOP/H6eCV05hqUhF+KYRxt9Y8tVMrpDZR2l75o6+xSbUOMu6xN+uVF0T9XzKcxmzTmnV7Na5up3QM3DoSRYX/EP3utr2+zAqpJIfKPLdA74w7g56oYWI9blpnpzxkEd3edVJOivUkpZ4JoenWManvIaSdMTJXMy3MtlQhva+j9CgguyVbUkdzK9KKEuah+pFZvaugtebsU+bllPTB0nlXGIJk98Ie9ZtxuY3nCKneB+KjKiXrAvXUPCI9mWkYS/1rggpFmu3HbXBnWSUdf localuser@machine.local

Select the public key, and copy it to your clipboard.

Add Public Key to New Remote User

To enable the use of SSH key to authenticate as the new remote user, you must add the public key to a special file in the user's home directory.

On the server, as the root user, enter the following command to switch to the new user (substitute your own user name):


su - demo

Now you will be in your new user's home directory.

Create a new directory called .ssh and restrict its permissions with the following commands:


mkdir .ssh

chmod 700 .ssh

Now open a file in .ssh called authorized_keys with a text editor. We will use vi to edit the file:


vi .ssh/authorized_keys

Enter insert mode, by pressing i, then enter your public key (which should be in your clipboard) by pasting it into the editor. Now hit ESC to leave insert mode.

Enter :x then ENTER to save and exit the file.

Now restrict the permissions of the authorized_keys file with this command:


chmod 600 .ssh/authorized_keys

Type this command once to return to the root user:


exit

Now you may SSH login as your new user, using the private key as authentication.

To read more about how key authentication works, read this tutorial: How To Configure SSH Key-Based Authentication on a Linux Server.

Step Five — Configure SSH Daemon

Now that we have our new account, we can secure our server a little bit by modifying its SSH daemon configuration (the program that allows us to log in remotely) to disallow remote SSH access to the rootaccount.

Begin by opening the configuration file with your text editor as root:


vi /etc/ssh/sshd_config

Here, we have the option to disable root login through SSH. This is generally a more secure setting since we can now access our server through our normal user account and escalate privileges when necessary.

To disable remote root logins, we need to find the line that looks like this:

/etc/ssh/sshd_config (before)

#PermitRootLogin yes

Hint: To search for this line, type /PermitRoot then hit ENTER. This should bring the cursor to the "P" character on that line.

Uncomment the line by deleting the "#" symbol (press Shift-x).

Now move the cursor to the "yes" by pressing c.

Now replace "yes" by pressing cw, then typing in "no". Hit Escape when you are done editing. It should look like this:

/etc/ssh/sshd_config (after)

PermitRootLogin no

Disabling remote root login is highly recommended on every server!

Enter :x then ENTER to save and exit the file.

Reload SSH

Now that we have made our changes, we need to restart the SSH service so that it will use our new configuration.

Type this to restart SSH:


systemctl reload sshd

Now, before we log out of the server, we should test our new configuration. We do not want to disconnect until we can confirm that new connections can be established successfully.

Open a new terminal window. In the new window, we need to begin a new connection to our server. This time, instead of using the root account, we want to use the new account that we created.

For the server that we configured above, connect using this command. Substitute your own information where it is appropriate:


ssh demo@SERVER_IP_ADDRESS

Note: If you are using PuTTY to connect to your servers, be sure to update the session's port number to match your server's current configuration.

You will be prompted for the new user's password that you configured. After that, you will be logged in as your new user.

Remember, if you need to run a command with root privileges, type "sudo" before it like this:


sudo command_to_run

If all is well, you can exit your sessions by typing:


exit

Where To Go From Here?

At this point, you have a solid foundation for your server. You can install any of the software you need on your server now.

If you are not sure what you want to do with your server, check out the next tutorial in this series for Additional Recommended Steps for New CentOS 7 Servers. It covers things like enabling fail2ban to reduce the effectiveness of brute force attacks, basic firewall settings, NTP, and swap files. It also provides links to tutorials that show you how to set up common web applications.

If you just want to explore, take a look at the rest of our community to find more tutorials. Some popular ideas are configuring a LAMP stack or a LEMP stack, which will
allow you to host websites.

Upgrade Apache 2.4.6 to 2.4.29 without losing config

noreply@blogger.com (Farhad) — Sun, 21 Jan 2018 06:52:00 +0000

Apache is the most widely used web server software for serving web applications and it is essential part of any server. To have the latest version installed, means that your software package will probably have more new features and known bugs fixes.

Introduction

In this tutorial I am going to describe simple steps to install the latest Apache (httpd) version on your Centos 7 system.

By default Centos 7 has few predefined repositories for installing packages, but unfortunately a lot of packages are out of date there.

Step 1 — Find out the Apache version in default repos

In order to check the current version of httpd package available in repositories – type the following command:

1	yum info httpd

If you have default installation, you will most likely see similar output.

[root@crosp ~]# yum info httpd
Loaded plugins: fastestmirror
epel/x86_64/metalink                                     |  19 kB     00:00
epel                                                     | 4.3 kB     00:00
(1/3): epel/x86_64/group_gz                                | 170 kB   00:00
(2/3): epel/x86_64/primary_db                              | 4.6 MB   00:00
(3/3): epel/x86_64/updateinfo                              | 780 kB   00:00
Loading mirror speeds from cached hostfile
 * base: mirrors.ircam.fr
 * epel: mirrors.ircam.fr
 * extras: centos.mirror.fr.planethoster.net
 * updates: centos.mirror.fr.planethoster.net
Available Packages
Name        : httpd
Arch        : x86_64
Version     : 2.4.6
Release     : 45.el7.centos.4
Size        : 2.7 M
Repo        : updates/7/x86_64
Summary     : Apache HTTP Server
URL         : http://httpd.apache.org/
License     : ASL 2.0
Description : The Apache HTTP Server is a powerful, efficient, and extensible
            : web server.

As you can see from the output above, there is only 2.4.6 Apache version available in default repos.

Please note:

Centos uses Security Backporting Practice in order to apply most recent fixes to older versions of a software package, as a result it doesn’t mean that an older version provided by default repositories is vulnerable. But in my case I didn’t have a required update.

You can see a changelog using these commands :

1 2	sudo yum install yum-changelog yum changelog httpd

Step 2 — Set up CodeIT repositories

There is a great custom repo created by these guys CodeIT It provides latest versions of web servers (Apache & Nginx).

Before setting up the CodeIT repository first of all you need to enable the EPEL. It satisfies some dependencies required by the CodeIT repo.

1	sudo yum install -y epel-release

Finally enable the CodeIT repository.

1	cd /etc/yum.repos.d && wget https://repo.codeit.guru/codeit.el7.repo

Then verify the Apache package version again and you should see something like that.

[root@crosp ~]# yum info httpd
Loaded plugins: changelog, fastestmirror
Loading mirror speeds from cached hostfile
 * base: centos.crazyfrogs.org
 * epel: mirror.23media.de
 * extras: mirrors.ircam.fr
 * updates: centos.mirror.fr.planethoster.net
Available Packages
Name        : httpd
Arch        : x86_64
Version     : 2.4.29
Release     : 3.el7.codeit
Size        : 1.4 M
Repo        : CodeIT/x86_64
Summary     : Apache HTTP Server
URL         : http://httpd.apache.org/
License     : ASL 2.0
Description : The Apache HTTP Server is a powerful, efficient, and extensible
            : web server.

Step 3 — Update the Apache web-server

Now you should have everything set up and upgrade to the latest Apache package.

1	yum upgrade httpd

Once Apache is installed, let’s start, restart or check the status of it and test whether it is working.

1	[root@crosp ~]# systemctl start httpd

Finally, tell systemd to start the Apache service automatically at boot.

1	[root@crosp ~]# systemctl enable httpd

That’s all, if you have any troubles please feel free to leave comments below.

Ref: https://stackoverflow.com/questions/45505411/upgrade-apache-2-4-6-to-2-4-27-without-losing-config

How To Update Or Install Openssl From Source To Latest Version

noreply@blogger.com (Farhad) — Sun, 21 Jan 2018 06:43:00 +0000

https://www.openssl.org/

Update Openssl

For Linux

Steps ( For Linux )

  wget http://www.openssl.org/source/openssl-1.0.2n.tar.gz
  tar -xvzf openssl-1.0.2n.tar.gz
  cd openssl-1.0.2n
  ./config --prefix=/usr/
  make
  sudo make install

Steps ( For Mac )

  wget http://www.openssl.org/source/openssl-1.0.2n.tar.gz
  tar -xvzf openssl-1.0.2n.tar.gz
  cd openssl-1.0.2n
  ./Configure darwin64-x86_64-cc --prefix=/usr
  make
  sudo make install

Now verify your installed openssl version by typing

openssl version

Ref: https://www.computersnyou.com/3155/update-install-openssl-source-latest-version/

How to Upgrade CentOS 7.4 from CentOS 7.3/7.2/7.1/7.0

noreply@blogger.com (Farhad) — Sun, 21 Jan 2018 06:31:00 +0000

CentOS 7.4 Released. Recently latest version of CentOS 7.4 has been released. All the CentOS 7.3, 7.2 7.1 and 7.0 users can upgrade their system to latest release. All the users running with WHM/cPanel don’t need to do anything. WHM/cPanel will automatically upgrade their operating system to next scheduled upgrade. If you are using CentOS without cPanel, this article is helpful for you for upgrading your current CentOS 7.x to latest CentOS 7.2

Step 1 – Check Your CentOS Version

CentOS systems keep version details in /etc/redhat-release and /etc/centos-release. You just need to check content of one of these files.

cat /etc/redhat-release

CentOS Linux release 7.3.1503 (Core)

Step 2 – Backup Important Data

Before upgrading centos make sure you have taken backup of all your data to the remote location. Below are few suggested items to take backup.

Backup all databases ( MySQL, PostgreSQL, etc.. )
Backup all configuration files ( Apache, PHP, MySQL, DNS and Other services )
Backup all websites data running in webserver
Backup other service if any running on system

Step 3 – Upgrade CentOS 7

Following are the steps to help you to upgrade CentOS to latest release. Use yum upgrade command to upgrade your current running system.

yum clean all
yum update

After successful completion of above command just reboot your system.

# reboot

Step 4 – Verify Upgrade

Finally verify that your system has been upgraded successfully. To confirm it check the /etc/redhat-release file content.

cat /etc/redhat-release

CentOS Linux release 7.4.1708 (Core)

Redirect http to https permanently in apache

noreply@blogger.com (Farhad) — Tue, 09 Jan 2018 17:22:00 +0000

Can be use in both virtualhost and HTACCESS file.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Hyperledger/blockchain-explorer Sample Application Setup

noreply@blogger.com (Farhad) — Tue, 12 Dec 2017 08:00:00 +0000

Hyperledger Explorer

Hyperledger Explorer is a simple, powerful, easy-to-use, highly maintainable, open source browser for viewing activity on the underlying blockchain network.

Directory Structure

├── app                    fabric GRPC interface
├── db      the mysql script and help class
├── explorer_client        Web Ui
├── first-network Basic fabric network setup
├── listener               websocket listener
├── metrics                metrics about tx count per minute and block count per minute
├── service                the service 
├── socket     push real time data to front end
├── timer                  Timer to post information periodically  
└── utils                  Various utility scripts

Requirements

Following are the software dependencies required to install and run hyperledger explorer

nodejs 6.9.x (Note that v7.x is not yet supported)
mysql 5.7 or greater

Hyperledger Explorer works with Hyperledger Fabric 1.0. Install the following software dependencies to manage fabric network.

docker 17.06.2-ce [https://www.docker.com/community-edition]
docker-compose 1.14.0 [https://docs.docker.com/compose/]

Clone Repository

Clone this repository to get the latest using the following command.

git clone https://github.com/hyperledger/blockchain-explorer.git
cd blockchain-explorer

Database setup

Run the database setup scripts located under db/fabricexplorer.sql

mysql -u -p < db/fabricexplorer.sql

Fabric network setup

This repository comes with a sample network configuration to start with

cd first-network
./bootstrap-1.0.2.sh - This is going to download the necessary binaries and hyperledger docker images.
mkdir -p ./channel-artifacts
./byfn.sh -m generate -c mychannel
./byfn.sh -m up -c mychannel

Alternatively you can setup your own network using Build your network tutorial from Fabric. Once you setup the network, please modify the values in network-config.json accordingly.

This brings up a 2 org network with channel name mychannel .

Running blockchain-explorer

On another terminal,

cd blockchain-explorer
Modify config.json to update the values for
- channels
- mysql host, username, password details
- tls

 "channelsList": ["mychannel"],
 "enableTls":true, 
 "mysql":{
      "host":"127.0.0.1",
      "database":"fabricexplorer",
      "username":"root",
      "passwd":"123456"
   }

npm install
./start.sh

Launch the URL http://localhost:8080 on a browser.

Screenshots

This is how the fabric-explorer looks like,

SIMPLE REST-API

This also provides a simple rest-api to access the following

Block
Transaction
Peer Status
List of chaincodes deployed

//get block info
curl -X POST  http://localhost:8080/api/block/json -H 'cache-control: no-cache' -H 'content-type: application/json' -d '{
    "number":"${block number}"
}'

//get transcation JOSN
curl -X POST  http://localhost:8080/api/tx/json -H 'cache-control: no-cache' -H 'content-type: application/json' -d '{
    "number":"${ Tx hex }"
}'


//get peer status
curl -X POST  http://localhost:8080/api/status/get -H 'cache-control: no-cache' -H 'content-type: application/json' -d ''

//get chaincode list
curl -X POST  http://localhost:8080/chaincodelist -H 'cache-control: no-cache' -H 'content-type: application/json' -d ''

Query to fetch channels

http://localhost:8080/apis/channels?peer=peer1

returns:

{"channels":[{"channel_id":"mychannel1"},{"channel_id":"mychannel2"}]}

Query to get BlockCount on a channel

http://localhost:8080/apis/channels/:channelname/height

example:

http://localhost:8080/apis/channels/mychannel1/height

returns:

11

Query to fetch all Installed/instantiated chaincodes


example:

http://localhost:8080/apis/chaincodes?channel=mychannel1

returns:

[{"name":"mycc","version":"v1","path":"github.com/uniqueKeyValue"}]

Query for Channel Information

http://localhost:8080/apis/channels/:channelName?peer=peer1

example:

http://localhost:8080/apis/channels/mychannel1?peer=peer1

returns:

{"height":{"low":11,"high":0,"unsigned":true},"currentBlockHash":{"buffer":{"type":"Buffer","data":[8,11,18,32,90,45,133,231,141,67,36,144,207,89,0,146,16,148,152,87,45,74,92,18,81,15,204,7,46,18,45,19,107,246,6,137,26,32,211,81,65,122,137,193,139,40,222,151,12,146,250,86,9,198,149,213,97,220,41,202,26,167,187,251,114,17,101,146,45,76]},"offset":4,"markedOffset":-1,"limit":36,"littleEndian":true,"noAssert":false},"previousBlockHash":{"buffer":{"type":"Buffer","data":[8,11,18,32,90,45,133,231,141,67,36,144,207,89,0,146,16,148,152,87,45,74,92,18,81,15,204,7,46,18,45,19,107,246,6,137,26,32,211,81,65,122,137,193,139,40,222,151,12,146,250,86,9,198,149,213,97,220,41,202,26,167,187,251,114,17,101,146,45,76]},"offset":38,"markedOffset":-1,"limit":70,"littleEndian":true,"noAssert":false}}

Query Get Block by Hash

http://localhost:8080/apis/channels/:channelName/blocks?peer=peer1&hash=blockHash

example:

http://localhost:8080/apis/channels/mychannel1/blocks?peer=peer1&hash=17edcc4ab8dbac1bca83d4108a24cb7708f1305c09df0908e90399df665a462d

returns:

{"header":{"number":{"low":0,"high":0,"unsigned":true},"previous_hash":"","data_hash":"0d37b6e459b5b1ab536488b459743497ca41756877395fd83cee1a247a18a7a6"},"data":{"data":[{"signature":{"type":"Buffer","data":[48,69,2,33,0,235,193,198,202,68,232,94,94,84,187,198,24,165,76,64,5,230,187,54,42,13,208,49,180,44,92,45,193,141,59,75,252,2,32,66,9,142,72,25,163,108,1,117,225,129,218,88,31,112,58,114,252,147,142,233,138,233,59,40,202,230,49,31,245,61,125]},"payload":{"header":{"channel_header":{"type":"CONFIG","version":1,"timestamp":"Thu Sep 28 2017 10:11:05 GMT+0800 (CST)","channel_id":"mychannel1","tx_id":"","epoch":0,"extension":{"type":"Buffer","data":[]}},"signature_header":{"creator":{"Mspid":"OrdererMSP","IdBytes":"-----BEGIN -----\nMIICDDCCAbOgAwIBAgIQOHE/ondSQMSlUNNQazSIXTAKBggqhkjOPQQDAjBpMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEUMBIGA1UEChMLZXhhbXBsZS5jb20xFzAVBgNVBAMTDmNhLmV4YW1w\nbGUuY29tMB4XDTE3MDcxNTAyMDYzNloXDTI3MDcxMzAyMDYzNlowWTELMAkGA1UE\nBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lz\nY28xHTAbBgNVBAMTFG9yZGVyZXIwLmV4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYI\nKoZIzj0DAQcDQgAEhaQ2UremZlrOMvYberqt4fppOO7pgYHrYou2fafNzk5Rdtp8\nGsP3hDum49p+9jLYzzp5c6zDCaLsjm+Xvl2zDqNNMEswDgYDVR0PAQH/BAQDAgeA\nMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAgrlTI/LkISeYsdjEWv9fZyWppSzBu\nr9kNeyV2jlUJkVswCgYIKoZIzj0EAwIDRwAwRAIgQuOrMWolp2iJrCG6R/3jVYRF\nuivJkRQsAkRnel25y6ACIDcxY4zuGR1cHEAIFlbvt3oq83mwIYcTF+mT1+caLkOL\n-----END -----\n"},"nonce":{"type":"Buffer","data":[112,94,14,11,197,72,6,126,254,29,66,47,220,119,125,132,27,139,0,212,3,129,213,76]}}},"data":{"config":{"sequence":{"low":1,"high":0,"unsigned":true},"channel_group":{"version":0,"groups":{"Orderer":{"version":0,"groups":{"OrdererMSP":{"version":0,"groups":{},"values":{"MSP":{"version":0,"mod_policy":"Admins","value":{"type":0,"config":{"name":"OrdererMSP","root_certs":["-----BEGIN CERTIFICATE-----\nMIICLzCCAdagAwIBAgIRAO7tuPK9KmxUdlKSx13kjs8wCgYIKoZIzj0EAwIwaTEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xFDASBgNVBAoTC2V4YW1wbGUuY29tMRcwFQYDVQQDEw5jYS5leGFt\ncGxlLmNvbTAeFw0xNzA3MTUwMjA2MzZaFw0yNzA3MTMwMjA2MzZaMGkxCzAJBgNV\nBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNp\nc2NvMRQwEgYDVQQKEwtleGFtcGxlLmNvbTEXMBUGA1UEAxMOY2EuZXhhbXBsZS5j\nb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARrwQalsz34OGRcWl2d6QaJt7YQ\nq+113l0rzqY6/eMNKkFU5mKuKlhEFlPje0uxEwCqBaN8qt+ErwoEGC+2ajWGo18w\nXTAOBgNVHQ8BAf8EBAMCAaYwDwYDVR0lBAgwBgYEVR0lADAPBgNVHRMBAf8EBTAD\nAQH/MCkGA1UdDgQiBCCuVMj8uQhJ5ix2MRa/19nJamlLMG6v2Q17JXaOVQmRWzAK\nBggqhkjOPQQDAgNHADBEAiBzzvzAhn8ZHHPFEeSRklweZATDzVSSg2UoRHmRzrfB\nyQIgC+y8O4EzLxvst/RWo2kKzCKaUULX3x8V4JitSjkfkyA=\n-----END CERTIFICATE-----\n"],"intermediate_certs":[],"admins":["-----BEGIN CERTIFICATE-----\nMIICCTCCAbCgAwIBAgIQO9MVJymGxa51LJnAD/+WCTAKBggqhkjOPQQDAjBpMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEUMBIGA1UEChMLZXhhbXBsZS5jb20xFzAVBgNVBAMTDmNhLmV4YW1w\nbGUuY29tMB4XDTE3MDcxNTAyMDYzNloXDTI3MDcxMzAyMDYzNlowVjELMAkGA1UE\nBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lz\nY28xGjAYBgNVBAMMEUFkbWluQGV4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZI\nzj0DAQcDQgAED098sJ5MWt+G+iTYndqxVJNYcc/9tQJNrGo6WT3y72GDKRvrjOJO\ngj9LESvfRkhR2DLUjrcOAWuxUFkQVl2Y8aNNMEswDgYDVR0PAQH/BAQDAgeAMAwG\nA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAgrlTI/LkISeYsdjEWv9fZyWppSzBur9kN\neyV2jlUJkVswCgYIKoZIzj0EAwIDRwAwRAIgNjM48iYrYHjLb4HtiWZSqJCSyip4\nQOINhia7Ox+sOkkCIBC7GSCNHUwjXF2W39ct+URK4w+6zpTXK17OoCPijCT6\n-----END CERTIFICATE-----\n"],"revocation_list":[],"signing_identity":null,"organizational_unit_identifiers":[]}}}},"policies":{"Admins":{"version":0,"mod_policy":"Admins","policy":{"type":"SIGNATURE","policy":{"version":0,"policy":{"Type":"n_out_of","n_out_of":{"N":1,"policies":[{"Type":"signed_by","signed_by":0}]}},"identities":[{"principal_classification":0,"msp_identifier":"OrdererMSP","Role":"ADMIN"}]}}},"Readers":{"version":0,"mod_policy":"Admins","policy":{"type":"SIGNATURE","policy":{"version":0,"policy":{"Type":"n_out_of","n_out_of":{"N":1,"policies":[{"Type":"signed_by","signed_by":0}]}},"identities":[{"principal_classification":0,"msp_identifier":"OrdererMSP","Role":"MEMBER"}]}}},"Writers":{"version":0,"mod_policy":"Admins","policy":{"type":"SIGNATURE","policy":{"version":0,"policy":{"Type":"n_out_of","n_out_of":{"N":1,"policies":[{"Type":"signed_by","signed_by":0}]}},"identities":[{"principal_classification":0,"msp_identifier":"OrdererMSP","Role":"MEMBER"}]}}}},"mod_policy":"Admins"}},"values":{"BatchSize":{"version":0,"mod_policy":"Admins","value":{"max_message_count":3,"absolute_max_bytes":102760448,"preferred_max_bytes":524288}},"BatchTimeout":{"version":0,"mod_policy":"Admins","value":{"timeout":"2s"}},"ChannelRestrictions":{"version":0,"mod_policy":"Admins","value":{"max_count":{"low":0,"high":0,"unsigned":true}}},"KafkaBrokers":{"version":0,"mod_policy":"Admins","value":{}},"ConsensusType":{"version":0,"mod_policy":"Admins","value":{"type":"kafka"}}},"policies":{"Readers":{"version":0,"mod_policy":"Admins","policy":{"type":"IMPLICIT_META","policy":{"sub_policy":"Readers","rule":"ANY"}}},"Writers":{"version":0,"mod_policy":"Admins","policy":{"type":"IMPLICIT_META","policy":{"sub_policy":"Writers","rule":"ANY"}}},"Admins":{"version":0,"mod_policy":"Admins","policy":{"type":"IMPLICIT_META","policy":{"sub_policy":"Admins","rule":"MAJORITY"}}},"BlockValidation":{"version":0,"mod_policy":"Admins","policy":{"type":"IMPLICIT_META","policy":{"sub_policy":"Writers","rule":"ANY"}}}},"mod_policy":"Admins"},"Application":{"version":1,"groups":{"Org1MSP":{"version":0,"groups":{},"values":{"MSP":{"version":0,"mod_policy":"Admins","value":{"type":0,"config":{"name":"Org1MSP","root_certs":["-----BEGIN CERTIFICATE-----\nMIICQzCCAeqgAwIBAgIRAMTkVne1BkUA+xrG1IucKzwwCgYIKoZIzj0EAwIwczEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xGTAXBgNVBAoTEG9yZzEuZXhhbXBsZS5jb20xHDAaBgNVBAMTE2Nh\nLm9yZzEuZXhhbXBsZS5jb20wHhcNMTcwNzE1MDIwNjM2WhcNMjcwNzEzMDIwNjM2\nWjBzMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMN\nU2FuIEZyYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UE\nAxMTY2Eub3JnMS5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IA\nBAKOsvBuwa68x3TYUlc915mlX1YkIjul1eiluBmwjKoEPNv9huuW81u14jqBiiyO\nfnssCPqIh81IPbiw7hN5GR+jXzBdMA4GA1UdDwEB/wQEAwIBpjAPBgNVHSUECDAG\nBgRVHSUAMA8GA1UdEwEB/wQFMAMBAf8wKQYDVR0OBCIEIHuoXLT6fErJvkxl4466\nzHfapm6CqPobUFL2jLQBLNY5MAoGCCqGSM49BAMCA0cAMEQCIG8p1VWO64Alyn/X\n1Sg29ub89B9qBpsh0r8aVdwrPD7AAiBFAMVmNlVW/4ez2qAFSLRDlv9WLEFtD7BF\nUis5K9ze1Q==\n-----END CERTIFICATE-----\n"],"intermediate_certs":[],"admins":["-----BEGIN CERTIFICATE-----\nMIICGDCCAb+gAwIBAgIQcSoGCOGOr4YBmSoZf3+xKDAKBggqhkjOPQQDAjBzMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UEAxMTY2Eu\nb3JnMS5leGFtcGxlLmNvbTAeFw0xNzA3MTUwMjA2MzZaFw0yNzA3MTMwMjA2MzZa\nMFsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T\nYW4gRnJhbmNpc2NvMR8wHQYDVQQDDBZBZG1pbkBvcmcxLmV4YW1wbGUuY29tMFkw\nEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE9ShZ73kVS0lIvaRV7eLhZaokkD1WAJ9i\n/A7Q+Wo4EmVjFE5Q+zxQ8XdYf+c3Qb/oujc4DBWoBfyu5h0CGmJ4TKNNMEswDgYD\nVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAge6hctPp8Ssm+\nTGXjjrrMd9qmboKo+htQUvaMtAEs1jkwCgYIKoZIzj0EAwIDRwAwRAIgAynT6AFB\n3cyecXoI8jpT1PYLxLlQDYtIKzLy9wLwpgoCICxT8Zkq2F8phZ7LDnpKmqELIAsW\nPFzJ3ihODDc6GqCk\n-----END CERTIFICATE-----\n"],"revocation_list":[],"signing_identity":null,"organizational_unit_identifiers":[]}}}},"policies":{"Writers":{"version":0,"mod_policy":"Admins","policy":{"type":"SIGNATURE","policy":{"version":0,"policy":{"Type":"n_out_of","n_out_of":{"N":1,"policies":[{"Type":"signed_by","signed_by":0}]}},"identities":[{"principal_classification":0,"msp_identifier":"Org1MSP","Role":"MEMBER"}]}}},"Admins":{"version":0,"mod_policy":"Admins","policy":{"type":"SIGNATURE","policy":{"version":0,"policy":{"Type":"n_out_of","n_out_of":{"N":1,"policies":[{"Type":"signed_by","signed_by":0}]}},"identities":[{"principal_classification":0,"msp_identifier":"Org1MSP","Role":"ADMIN"}]}}},"Readers":{"version":0,"mod_policy":"Admins","policy":{"type":"SIGNATURE","policy":{"version":0,"policy":{"Type":"n_out_of","n_out_of":{"N":1,"policies":[{"Type":"signed_by","signed_by":0}]}},"identities":[{"principal_classification":0,"msp_identifier":"Org1MSP","Role":"MEMBER"}]}}}},"mod_policy":"Admins"},"Org2MSP":{"version":0,"groups":{},"values":{"MSP":{"version":0,"mod_policy":"Admins","value":{"type":0,"config":{"name":"Org2MSP","root_certs":["-----BEGIN CERTIFICATE-----\nMIICRDCCAeqgAwIBAgIRAOAK6UNPLpdERhKmnBd05RYwCgYIKoZIzj0EAwIwczEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xGTAXBgNVBAoTEG9yZzIuZXhhbXBsZS5jb20xHDAaBgNVBAMTE2Nh\nLm9yZzIuZXhhbXBsZS5jb20wHhcNMTcwNzE1MDIwNjM2WhcNMjcwNzEzMDIwNjM2\nWjBzMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMN\nU2FuIEZyYW5jaXNjbzEZMBcGA1UEChMQb3JnMi5leGFtcGxlLmNvbTEcMBoGA1UE\nAxMTY2Eub3JnMi5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IA\nBGiYV2PdPnvwA0EYnm2Elhfq12yF2+le6QsJR+S7wYKiE/Uaa3LF3w7GQ2DFltqt\nS3lZVo8dmeWUqehwkOfdew6jXzBdMA4GA1UdDwEB/wQEAwIBpjAPBgNVHSUECDAG\nBgRVHSUAMA8GA1UdEwEB/wQFMAMBAf8wKQYDVR0OBCIEIEGIqeaKQHLFUoz4lbUG\nlBL8Z5gRKToptVGcAgnWIW4bMAoGCCqGSM49BAMCA0gAMEUCIQDruLry79r1Vfrg\nnrXaBNBUFM8rgb9YCTlEkFpr2z41bgIgVcs7ZZE1H2m+mv7GYIONKlq8tFc4fu45\nd/EQIdCoCPU=\n-----END CERTIFICATE-----\n"],"intermediate_certs":[],"admins":["-----BEGIN CERTIFICATE-----\nMIICGDCCAb+gAwIBAgIQQE26BPVgQfIchcdcirObmjAKBggqhkjOPQQDAjBzMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMi5leGFtcGxlLmNvbTEcMBoGA1UEAxMTY2Eu\nb3JnMi5leGFtcGxlLmNvbTAeFw0xNzA3MTUwMjA2MzZaFw0yNzA3MTMwMjA2MzZa\nMFsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T\nYW4gRnJhbmNpc2NvMR8wHQYDVQQDDBZBZG1pbkBvcmcyLmV4YW1wbGUuY29tMFkw\nEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEP9miyVrFxkYxDSeGcxnj5SWYdzMRorw7\nN2Gagvm6yUBfEszIFJQZvarC1pIIFqpC8b8q+ZI4zLWn1HYGcvYj4KNNMEswDgYD\nVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAgQYip5opAcsVS\njPiVtQaUEvxnmBEpOim1UZwCCdYhbhswCgYIKoZIzj0EAwIDRwAwRAIgGC37d8De\nx9fubLTwf07GzEd4ds5V643MW1lD3V6wcLMCIDjpr+mIl/4qPZTui6QEb9GHwd2D\nfxsBBk1JfiImxMTj\n-----END CERTIFICATE-----\n"],"revocation_list":[],"signing_identity":null,"organizational_unit_identifiers":[]}}}},"policies":{"Admins":{"version":0,"mod_policy":"Admins","policy":{"type":"SIGNATURE","policy":{"version":0,"policy":{"Type":"n_out_of","n_out_of":{"N":1,"policies":[{"Type":"signed_by","signed_by":0}]}},"identities":[{"principal_classification":0,"msp_identifier":"Org2MSP","Role":"ADMIN"}]}}},"Readers":{"version":0,"mod_policy":"Admins","policy":{"type":"SIGNATURE","policy":{"version":0,"policy":{"Type":"n_out_of","n_out_of":{"N":1,"policies":[{"Type":"signed_by","signed_by":0}]}},"identities":[{"principal_classification":0,"msp_identifier":"Org2MSP","Role":"MEMBER"}]}}},"Writers":{"version":0,"mod_policy":"Admins","policy":{"type":"SIGNATURE","policy":{"version":0,"policy":{"Type":"n_out_of","n_out_of":{"N":1,"policies":[{"Type":"signed_by","signed_by":0}]}},"identities":[{"principal_classification":0,"msp_identifier":"Org2MSP","Role":"MEMBER"}]}}}},"mod_policy":"Admins"}},"values":{},"policies":{"Admins":{"version":0,"mod_policy":"","policy":{"type":"IMPLICIT_META","policy":{"sub_policy":"Admins","rule":"MAJORITY"}}},"Writers":{"version":0,"mod_policy":"","policy":{"type":"IMPLICIT_META","policy":{"sub_policy":"Writers","rule":"ANY"}}},"Readers":{"version":0,"mod_policy":"","policy":{"type":"IMPLICIT_META","policy":{"sub_policy":"Readers","rule":"ANY"}}}},"mod_policy":"Admins"}},"values":{"BlockDataHashingStructure":{"version":0,"mod_policy":"Admins","value":{"width":4294967295}},"OrdererAddresses":{"version":0,"mod_policy":"/Channel/Orderer/Admins","value":{"addresses":["orderer0.example.com:7050","orderer1.example.com:7050","orderer2.example.com:7050"]}},"Consortium":{"version":0,"mod_policy":"","value":{"name":"SampleConsortium"}},"HashingAlgorithm":{"version":0,"mod_policy":"Admins","value":{"name":"SHA256"}}},"policies":{"Admins":{"version":0,"mod_policy":"Admins","policy":{"type":"IMPLICIT_META","policy":{"sub_policy":"Admins","rule":"MAJORITY"}}},"Readers":{"version":0,"mod_policy":"Admins","policy":{"type":"IMPLICIT_META","policy":{"sub_policy":"Readers","rule":"ANY"}}},"Writers":{"version":0,"mod_policy":"Admins","policy":{"type":"IMPLICIT_META","policy":{"sub_policy":"Writers","rule":"ANY"}}}},"mod_policy":""}},"last_update":{"payload":{"header":{"channel_header":{"type":"CONFIG_UPDATE","version":2,"timestamp":"Thu Sep 28 2017 10:11:05 GMT+0800 (CST)","channel_id":"mychannel1","tx_id":"9276c884f36cbd751acc38ca21219c741b936702246c2bdb13821d0199ae5193","epoch":0,"extension":{"type":"Buffer","data":[]}},"signature_header":{"creator":{"Mspid":"Org1MSP","IdBytes":"-----BEGIN CERTIFICATE-----\nMIICGDCCAb+gAwIBAgIQcSoGCOGOr4YBmSoZf3+xKDAKBggqhkjOPQQDAjBzMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UEAxMTY2Eu\nb3JnMS5leGFtcGxlLmNvbTAeFw0xNzA3MTUwMjA2MzZaFw0yNzA3MTMwMjA2MzZa\nMFsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T\nYW4gRnJhbmNpc2NvMR8wHQYDVQQDDBZBZG1pbkBvcmcxLmV4YW1wbGUuY29tMFkw\nEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE9ShZ73kVS0lIvaRV7eLhZaokkD1WAJ9i\n/A7Q+Wo4EmVjFE5Q+zxQ8XdYf+c3Qb/oujc4DBWoBfyu5h0CGmJ4TKNNMEswDgYD\nVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAge6hctPp8Ssm+\nTGXjjrrMd9qmboKo+htQUvaMtAEs1jkwCgYIKoZIzj0EAwIDRwAwRAIgAynT6AFB\n3cyecXoI8jpT1PYLxLlQDYtIKzLy9wLwpgoCICxT8Zkq2F8phZ7LDnpKmqELIAsW\nPFzJ3ihODDc6GqCk\n-----END CERTIFICATE-----\n"},"nonce":{"type":"Buffer","data":[43,139,71,235,5,13,93,235,212,213,247,31,150,236,178,78,32,5,207,37,120,72,141,63]}}},"data":{"config_update":{"channel_id":"mychannel1","read_set":{"version":0,"groups":{"Application":{"version":0,"groups":{"Org1MSP":{"version":0,"groups":{},"values":{},"policies":{},"mod_policy":""},"Org2MSP":{"version":0,"groups":{},"values":{},"policies":{},"mod_policy":""}},"values":{},"policies":{},"mod_policy":""}},"values":{"Consortium":{"version":0,"mod_policy":"","value":{"name":"SampleConsortium"}}},"policies":{},"mod_policy":""},"write_set":{"version":0,"groups":{"Application":{"version":1,"groups":{"Org1MSP":{"version":0,"groups":{},"values":{},"policies":{},"mod_policy":""},"Org2MSP":{"version":0,"groups":{},"values":{},"policies":{},"mod_policy":""}},"values":{},"policies":{"Admins":{"version":0,"mod_policy":"","policy":{"type":"IMPLICIT_META","policy":{"sub_policy":"Admins","rule":"MAJORITY"}}},"Writers":{"version":0,"mod_policy":"","policy":{"type":"IMPLICIT_META","policy":{"sub_policy":"Writers","rule":"ANY"}}},"Readers":{"version":0,"mod_policy":"","policy":{"type":"IMPLICIT_META","policy":{"sub_policy":"Readers","rule":"ANY"}}}},"mod_policy":"Admins"}},"values":{"Consortium":{"version":0,"mod_policy":"","value":{"name":"SampleConsortium"}}},"policies":{},"mod_policy":""}},"signatures":[{"signature_header":{"creator":{"Mspid":"Org1MSP","IdBytes":"-----BEGIN CERTIFICATE-----\nMIICGDCCAb+gAwIBAgIQcSoGCOGOr4YBmSoZf3+xKDAKBggqhkjOPQQDAjBzMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UEAxMTY2Eu\nb3JnMS5leGFtcGxlLmNvbTAeFw0xNzA3MTUwMjA2MzZaFw0yNzA3MTMwMjA2MzZa\nMFsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T\nYW4gRnJhbmNpc2NvMR8wHQYDVQQDDBZBZG1pbkBvcmcxLmV4YW1wbGUuY29tMFkw\nEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE9ShZ73kVS0lIvaRV7eLhZaokkD1WAJ9i\n/A7Q+Wo4EmVjFE5Q+zxQ8XdYf+c3Qb/oujc4DBWoBfyu5h0CGmJ4TKNNMEswDgYD\nVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAge6hctPp8Ssm+\nTGXjjrrMd9qmboKo+htQUvaMtAEs1jkwCgYIKoZIzj0EAwIDRwAwRAIgAynT6AFB\n3cyecXoI8jpT1PYLxLlQDYtIKzLy9wLwpgoCICxT8Zkq2F8phZ7LDnpKmqELIAsW\nPFzJ3ihODDc6GqCk\n-----END CERTIFICATE-----\n"},"nonce":{"type":"Buffer","data":[22,72,248,96,183,237,7,68,93,154,2,218,248,1,10,72,92,24,175,210,127,226,60,255]}},"sigature":{"type":"Buffer","data":[48,67,2,32,76,141,129,192,143,172,36,250,136,141,92,185,150,174,60,106,161,60,194,82,63,190,130,225,187,211,196,74,172,222,7,181,2,31,104,149,126,161,206,128,183,254,57,136,143,189,93,217,140,188,221,169,220,102,234,154,223,8,132,60,85,149,152,21,192]}}]}},"signature":{"type":"Buffer","data":[48,69,2,33,0,146,151,131,117,5,81,236,2,113,198,126,10,4,91,110,90,89,12,245,161,219,154,222,102,194,47,98,6,141,88,177,110,2,32,114,169,151,5,216,117,124,89,52,10,76,238,177,136,201,71,203,162,140,198,64,72,43,159,111,155,224,84,48,145,214,197]}}}}}]},"metadata":{"metadata":[{"value":"","signatures":[]},{"value":{"index":{"low":0,"high":0,"unsigned":true}},"signatures":[]},[]]}}

Query Get Transaction by Transaction ID


http://localhost:8080/apis/channels/:channeName/transactions/:txid?peer=peer1

example:

http://localhost:8080/apis/channels/mychannel1/transactions/a19085e35ecb78a83cd2ae6762ae46c0924c765e16d6e5afc51492b522e0ceca?peer=peer1

returns:

{"validationCode":0,"transactionEnvelope":{"signature":{"type":"Buffer","data":[48,69,2,33,0,149,175,192,18,254,216,10,188,108,248,48,93,94,245,76,116,24,110,82,229,117,109,116,114,63,62,73,110,82,242,11,121,2,32,24,221,131,22,192,165,150,133,71,69,13,163,170,41,169,129,17,79,150,20,30,231,45,97,243,253,174,195,166,56,235,227]},"payload":{"header":{"channel_header":{"type":"ENDORSER_TRANSACTION","version":3,"timestamp":"Thu Sep 28 2017 10:11:26 GMT+0800 (CST)","channel_id":"mychannel1","tx_id":"a19085e35ecb78a83cd2ae6762ae46c0924c765e16d6e5afc51492b522e0ceca","epoch":0,"extension":{"type":"Buffer","data":[18,6,18,4,108,115,99,99]}},"signature_header":{"creator":{"Mspid":"Org1MSP","IdBytes":"-----BEGIN CERTIFICATE-----\nMIICGDCCAb+gAwIBAgIQcSoGCOGOr4YBmSoZf3+xKDAKBggqhkjOPQQDAjBzMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UEAxMTY2Eu\nb3JnMS5leGFtcGxlLmNvbTAeFw0xNzA3MTUwMjA2MzZaFw0yNzA3MTMwMjA2MzZa\nMFsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T\nYW4gRnJhbmNpc2NvMR8wHQYDVQQDDBZBZG1pbkBvcmcxLmV4YW1wbGUuY29tMFkw\nEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE9ShZ73kVS0lIvaRV7eLhZaokkD1WAJ9i\n/A7Q+Wo4EmVjFE5Q+zxQ8XdYf+c3Qb/oujc4DBWoBfyu5h0CGmJ4TKNNMEswDgYD\nVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAge6hctPp8Ssm+\nTGXjjrrMd9qmboKo+htQUvaMtAEs1jkwCgYIKoZIzj0EAwIDRwAwRAIgAynT6AFB\n3cyecXoI8jpT1PYLxLlQDYtIKzLy9wLwpgoCICxT8Zkq2F8phZ7LDnpKmqELIAsW\nPFzJ3ihODDc6GqCk\n-----END CERTIFICATE-----\n"},"nonce":{"type":"Buffer","data":[1,179,210,163,179,35,107,187,114,229,11,173,206,227,107,62,86,88,80,58,62,145,165,145]}}},"data":{"actions":[{"header":{"creator":{"Mspid":"Org1MSP","IdBytes":"-----BEGIN CERTIFICATE-----\nMIICGDCCAb+gAwIBAgIQcSoGCOGOr4YBmSoZf3+xKDAKBggqhkjOPQQDAjBzMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UEAxMTY2Eu\nb3JnMS5leGFtcGxlLmNvbTAeFw0xNzA3MTUwMjA2MzZaFw0yNzA3MTMwMjA2MzZa\nMFsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T\nYW4gRnJhbmNpc2NvMR8wHQYDVQQDDBZBZG1pbkBvcmcxLmV4YW1wbGUuY29tMFkw\nEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE9ShZ73kVS0lIvaRV7eLhZaokkD1WAJ9i\n/A7Q+Wo4EmVjFE5Q+zxQ8XdYf+c3Qb/oujc4DBWoBfyu5h0CGmJ4TKNNMEswDgYD\nVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAge6hctPp8Ssm+\nTGXjjrrMd9qmboKo+htQUvaMtAEs1jkwCgYIKoZIzj0EAwIDRwAwRAIgAynT6AFB\n3cyecXoI8jpT1PYLxLlQDYtIKzLy9wLwpgoCICxT8Zkq2F8phZ7LDnpKmqELIAsW\nPFzJ3ihODDc6GqCk\n-----END CERTIFICATE-----\n"},"nonce":{"type":"Buffer","data":[1,179,210,163,179,35,107,187,114,229,11,173,206,227,107,62,86,88,80,58,62,145,165,145]}},"payload":{"chaincode_proposal_payload":{"input":{"type":"Buffer","data":[10,122,8,1,18,6,18,4,108,115,99,99,26,110,10,6,100,101,112,108,111,121,10,10,109,121,99,104,97,110,110,101,108,49,10,26,10,24,8,1,18,10,18,4,109,121,99,99,26,2,118,48,26,8,10,4,105,110,105,116,10,0,10,60,18,16,18,14,8,1,18,2,8,0,18,2,8,1,18,2,8,2,26,14,18,12,10,10,79,114,100,101,114,101,114,77,83,80,26,11,18,9,10,7,79,114,103,49,77,83,80,26,11,18,9,10,7,79,114,103,50,77,83,80]}},"action":{"proposal_response_payload":{"proposal_hash":"9b247c653f3e92ec6f58dde261dfee3511627a1af2964813825edeb88df3c06f","extension":{"results":{"data_model":0,"ns_rwset":[{"namespace":"lscc","rwset":{"reads":[{"key":"mycc","version":null}],"range_queries_info":[],"writes":[{"key":"mycc","is_delete":false,"value":"\n\u0004mycc\u0012\u0002v0\u001a\u0004escc\"\u0004vscc*<\u0012\u0010\u0012\u000e\b\u0001\u0012\u0002\b\u0000\u0012\u0002\b\u0001\u0012\u0002\b\u0002\u001a\u000e\u0012\f\n\nOrdererMSP\u001a\u000b\u0012\t\n\u0007Org1MSP\u001a\u000b\u0012\t\n\u0007Org2MSP2D\n �jO������Cgt��\u0000S ��\u0012��!�-�\u0001u6���\u0012 *PI�w�\u000fjL5x6^�E=�)ˡF��\t\u0019\u0015��C5\u00115: \u001a�[$�\u001f�\u0013؉]�R74\u001fGƆ2��+�5.�z��G�B,\u0012\f\u0012\n\b\u0001\u0012\u0002\b\u0000\u0012\u0002\b\u0001\u001a\r\u0012\u000b\n\u0007Org1MSP\u0010\u0001\u001a\r\u0012\u000b\n\u0007Org2MSP\u0010\u0001"}]}}]},"events":{"chaincode_id":"","tx_id":"","event_name":"","payload":{"type":"Buffer","data":[]}},"response":{"status":200,"message":"","payload":"\n\u0004mycc\u0012\u0002v0\u001a\u0004escc\"\u0004vscc*<\u0012\u0010\u0012\u000e\b\u0001\u0012\u0002\b\u0000\u0012\u0002\b\u0001\u0012\u0002\b\u0002\u001a\u000e\u0012\f\n\nOrdererMSP\u001a\u000b\u0012\t\n\u0007Org1MSP\u001a\u000b\u0012\t\n\u0007Org2MSP2D\n �jO������Cgt��\u0000S ��\u0012��!�-�\u0001u6���\u0012 *PI�w�\u000fjL5x6^�E=�)ˡF��\t\u0019\u0015��C5\u00115: \u001a�[$�\u001f�\u0013؉]�R74\u001fGƆ2��+�5.�z��G�B,\u0012\f\u0012\n\b\u0001\u0012\u0002\b\u0000\u0012\u0002\b\u0001\u001a\r\u0012\u000b\n\u0007Org1MSP\u0010\u0001\u001a\r\u0012\u000b\n\u0007Org2MSP\u0010\u0001"}}},"endorsements":[{"endorser":{"Mspid":"Org1MSP","IdBytes":"-----BEGIN -----\nMIICGDCCAb+gAwIBAgIQXORLj+M+bZmvRJoszFNTLzAKBggqhkjOPQQDAjBzMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UEAxMTY2Eu\nb3JnMS5leGFtcGxlLmNvbTAeFw0xNzA3MTUwMjA2MzZaFw0yNzA3MTMwMjA2MzZa\nMFsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T\nYW4gRnJhbmNpc2NvMR8wHQYDVQQDExZwZWVyMC5vcmcxLmV4YW1wbGUuY29tMFkw\nEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqx9TvzAVDCYkcI7PolGydUptHN4s59n5\nPlWCCYNLkLvfHZRSYlZV+ZtEJTJuVsS+0cFe9mK4no8DsESvKy3fFqNNMEswDgYD\nVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAge6hctPp8Ssm+\nTGXjjrrMd9qmboKo+htQUvaMtAEs1jkwCgYIKoZIzj0EAwIDRwAwRAIgdHMM2mnd\nCYQg7tNXlxCeeCXimerCBZI2c0Jq79Pi3X8CIA5AN0pyIuDnl05c7sugzpYtMoKq\nZPNHf5DiHsG9Ddx0\n-----END -----\n"},"signature":{"type":"Buffer","data":[48,68,2,32,44,155,59,238,100,189,209,112,135,105,125,202,163,152,90,6,77,93,239,73,128,22,42,225,191,212,145,34,216,178,184,18,2,32,122,82,29,77,119,60,169,203,52,136,35,193,44,155,134,75,107,69,32,137,251,170,97,0,88,236,253,78,153,184,246,22]}},{"endorser":{"Mspid":"Org1MSP","IdBytes":"-----BEGIN -----\nMIICGDCCAb+gAwIBAgIQR6SpGhVy3iGFbuqxW/UmgjAKBggqhkjOPQQDAjBzMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UEAxMTY2Eu\nb3JnMS5leGFtcGxlLmNvbTAeFw0xNzA3MTUwMjA2MzZaFw0yNzA3MTMwMjA2MzZa\nMFsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T\nYW4gRnJhbmNpc2NvMR8wHQYDVQQDExZwZWVyMS5vcmcxLmV4YW1wbGUuY29tMFkw\nEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8lS4rakieycXrWvkqpitrL1BOtTpB8d+\nrIQd1Dq0851vTwFtKOGM+/AyZj3YFmPquLyjh+Y/f8gEOhl2ukbxaKNNMEswDgYD\nVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAge6hctPp8Ssm+\nTGXjjrrMd9qmboKo+htQUvaMtAEs1jkwCgYIKoZIzj0EAwIDRwAwRAIgdNm6ogr4\nh5IOGqgxvxKQIgcVotBWSE22ienKZMxaMsACICH02+7VWNGoegJIxh3uSbSxczUd\nkIq+MzhhkpPKGly7\n-----END -----\n"},"signature":{"type":"Buffer","data":[48,69,2,33,0,175,157,205,24,107,173,2,11,115,93,222,233,81,233,62,154,58,80,174,140,163,75,69,134,90,10,6,208,190,197,97,64,2,32,85,188,87,232,107,88,209,230,47,166,33,55,144,122,127,96,254,233,232,126,135,142,197,32,244,185,161,153,55,158,145,53]}}]}}}]}}}}

Query Get Block by BlockNumber

http://localhost:8080/apis/channels/:channelName/blocks/:blockNumber?peer=peer1

example:

http://localhost:8080/apis/channels/mychannel1/blocks/1?peer=peer1

returns:

{"header":{"number":{"low":1,"high":0,"unsigned":true},"previous_hash":"17edcc4ab8dbac1bca83d4108a24cb7708f1305c09df0908e90399df665a462d","data_hash":"5d0ce069c0d1832a1860459293573d1b16fda1504a94718840e6a4531f2933c4"},"data":{"data":[{"signature":{"type":"Buffer","data":[48,69,2,33,0,149,175,192,18,254,216,10,188,108,248,48,93,94,245,76,116,24,110,82,229,117,109,116,114,63,62,73,110,82,242,11,121,2,32,24,221,131,22,192,165,150,133,71,69,13,163,170,41,169,129,17,79,150,20,30,231,45,97,243,253,174,195,166,56,235,227]},"payload":{"header":{"channel_header":{"type":"ENDORSER_TRANSACTION","version":3,"timestamp":"Thu Sep 28 2017 10:11:26 GMT+0800 (CST)","channel_id":"mychannel1","tx_id":"a19085e35ecb78a83cd2ae6762ae46c0924c765e16d6e5afc51492b522e0ceca","epoch":0,"extension":{"type":"Buffer","data":[18,6,18,4,108,115,99,99]}},"signature_header":{"creator":{"Mspid":"Org1MSP","IdBytes":"-----BEGIN CERTIFICATE-----\nMIICGDCCAb+gAwIBAgIQcSoGCOGOr4YBmSoZf3+xKDAKBggqhkjOPQQDAjBzMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UEAxMTY2Eu\nb3JnMS5leGFtcGxlLmNvbTAeFw0xNzA3MTUwMjA2MzZaFw0yNzA3MTMwMjA2MzZa\nMFsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T\nYW4gRnJhbmNpc2NvMR8wHQYDVQQDDBZBZG1pbkBvcmcxLmV4YW1wbGUuY29tMFkw\nEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE9ShZ73kVS0lIvaRV7eLhZaokkD1WAJ9i\n/A7Q+Wo4EmVjFE5Q+zxQ8XdYf+c3Qb/oujc4DBWoBfyu5h0CGmJ4TKNNMEswDgYD\nVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAge6hctPp8Ssm+\nTGXjjrrMd9qmboKo+htQUvaMtAEs1jkwCgYIKoZIzj0EAwIDRwAwRAIgAynT6AFB\n3cyecXoI8jpT1PYLxLlQDYtIKzLy9wLwpgoCICxT8Zkq2F8phZ7LDnpKmqELIAsW\nPFzJ3ihODDc6GqCk\n-----END CERTIFICATE-----\n"},"nonce":{"type":"Buffer","data":[1,179,210,163,179,35,107,187,114,229,11,173,206,227,107,62,86,88,80,58,62,145,165,145]}}},"data":{"actions":[{"header":{"creator":{"Mspid":"Org1MSP","IdBytes":"-----BEGIN CERTIFICATE-----\nMIICGDCCAb+gAwIBAgIQcSoGCOGOr4YBmSoZf3+xKDAKBggqhkjOPQQDAjBzMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UEAxMTY2Eu\nb3JnMS5leGFtcGxlLmNvbTAeFw0xNzA3MTUwMjA2MzZaFw0yNzA3MTMwMjA2MzZa\nMFsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T\nYW4gRnJhbmNpc2NvMR8wHQYDVQQDDBZBZG1pbkBvcmcxLmV4YW1wbGUuY29tMFkw\nEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE9ShZ73kVS0lIvaRV7eLhZaokkD1WAJ9i\n/A7Q+Wo4EmVjFE5Q+zxQ8XdYf+c3Qb/oujc4DBWoBfyu5h0CGmJ4TKNNMEswDgYD\nVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAge6hctPp8Ssm+\nTGXjjrrMd9qmboKo+htQUvaMtAEs1jkwCgYIKoZIzj0EAwIDRwAwRAIgAynT6AFB\n3cyecXoI8jpT1PYLxLlQDYtIKzLy9wLwpgoCICxT8Zkq2F8phZ7LDnpKmqELIAsW\nPFzJ3ihODDc6GqCk\n-----END CERTIFICATE-----\n"},"nonce":{"type":"Buffer","data":[1,179,210,163,179,35,107,187,114,229,11,173,206,227,107,62,86,88,80,58,62,145,165,145]}},"payload":{"chaincode_proposal_payload":{"input":{"type":"Buffer","data":[10,122,8,1,18,6,18,4,108,115,99,99,26,110,10,6,100,101,112,108,111,121,10,10,109,121,99,104,97,110,110,101,108,49,10,26,10,24,8,1,18,10,18,4,109,121,99,99,26,2,118,48,26,8,10,4,105,110,105,116,10,0,10,60,18,16,18,14,8,1,18,2,8,0,18,2,8,1,18,2,8,2,26,14,18,12,10,10,79,114,100,101,114,101,114,77,83,80,26,11,18,9,10,7,79,114,103,49,77,83,80,26,11,18,9,10,7,79,114,103,50,77,83,80]}},"action":{"proposal_response_payload":{"proposal_hash":"9b247c653f3e92ec6f58dde261dfee3511627a1af2964813825edeb88df3c06f","extension":{"results":{"data_model":0,"ns_rwset":[{"namespace":"lscc","rwset":{"reads":[{"key":"mycc","version":null}],"range_queries_info":[],"writes":[{"key":"mycc","is_delete":false,"value":"\n\u0004mycc\u0012\u0002v0\u001a\u0004escc\"\u0004vscc*<\u0012\u0010\u0012\u000e\b\u0001\u0012\u0002\b\u0000\u0012\u0002\b\u0001\u0012\u0002\b\u0002\u001a\u000e\u0012\f\n\nOrdererMSP\u001a\u000b\u0012\t\n\u0007Org1MSP\u001a\u000b\u0012\t\n\u0007Org2MSP2D\n �jO������Cgt��\u0000S ��\u0012��!�-�\u0001u6���\u0012 *PI�w�\u000fjL5x6^�E=�)ˡF��\t\u0019\u0015��C5\u00115: \u001a�[$�\u001f�\u0013؉]�R74\u001fGƆ2��+�5.�z��G�B,\u0012\f\u0012\n\b\u0001\u0012\u0002\b\u0000\u0012\u0002\b\u0001\u001a\r\u0012\u000b\n\u0007Org1MSP\u0010\u0001\u001a\r\u0012\u000b\n\u0007Org2MSP\u0010\u0001"}]}}]},"events":{"chaincode_id":"","tx_id":"","event_name":"","payload":{"type":"Buffer","data":[]}},"response":{"status":200,"message":"","payload":"\n\u0004mycc\u0012\u0002v0\u001a\u0004escc\"\u0004vscc*<\u0012\u0010\u0012\u000e\b\u0001\u0012\u0002\b\u0000\u0012\u0002\b\u0001\u0012\u0002\b\u0002\u001a\u000e\u0012\f\n\nOrdererMSP\u001a\u000b\u0012\t\n\u0007Org1MSP\u001a\u000b\u0012\t\n\u0007Org2MSP2D\n �jO������Cgt��\u0000S ��\u0012��!�-�\u0001u6���\u0012 *PI�w�\u000fjL5x6^�E=�)ˡF��\t\u0019\u0015��C5\u00115: \u001a�[$�\u001f�\u0013؉]�R74\u001fGƆ2��+�5.�z��G�B,\u0012\f\u0012\n\b\u0001\u0012\u0002\b\u0000\u0012\u0002\b\u0001\u001a\r\u0012\u000b\n\u0007Org1MSP\u0010\u0001\u001a\r\u0012\u000b\n\u0007Org2MSP\u0010\u0001"}}},"endorsements":[{"endorser":{"Mspid":"Org1MSP","IdBytes":"-----BEGIN -----\nMIICGDCCAb+gAwIBAgIQXORLj+M+bZmvRJoszFNTLzAKBggqhkjOPQQDAjBzMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UEAxMTY2Eu\nb3JnMS5leGFtcGxlLmNvbTAeFw0xNzA3MTUwMjA2MzZaFw0yNzA3MTMwMjA2MzZa\nMFsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T\nYW4gRnJhbmNpc2NvMR8wHQYDVQQDExZwZWVyMC5vcmcxLmV4YW1wbGUuY29tMFkw\nEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqx9TvzAVDCYkcI7PolGydUptHN4s59n5\nPlWCCYNLkLvfHZRSYlZV+ZtEJTJuVsS+0cFe9mK4no8DsESvKy3fFqNNMEswDgYD\nVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAge6hctPp8Ssm+\nTGXjjrrMd9qmboKo+htQUvaMtAEs1jkwCgYIKoZIzj0EAwIDRwAwRAIgdHMM2mnd\nCYQg7tNXlxCeeCXimerCBZI2c0Jq79Pi3X8CIA5AN0pyIuDnl05c7sugzpYtMoKq\nZPNHf5DiHsG9Ddx0\n-----END -----\n"},"signature":{"type":"Buffer","data":[48,68,2,32,44,155,59,238,100,189,209,112,135,105,125,202,163,152,90,6,77,93,239,73,128,22,42,225,191,212,145,34,216,178,184,18,2,32,122,82,29,77,119,60,169,203,52,136,35,193,44,155,134,75,107,69,32,137,251,170,97,0,88,236,253,78,153,184,246,22]}},{"endorser":{"Mspid":"Org1MSP","IdBytes":"-----BEGIN -----\nMIICGDCCAb+gAwIBAgIQR6SpGhVy3iGFbuqxW/UmgjAKBggqhkjOPQQDAjBzMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UEAxMTY2Eu\nb3JnMS5leGFtcGxlLmNvbTAeFw0xNzA3MTUwMjA2MzZaFw0yNzA3MTMwMjA2MzZa\nMFsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T\nYW4gRnJhbmNpc2NvMR8wHQYDVQQDExZwZWVyMS5vcmcxLmV4YW1wbGUuY29tMFkw\nEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8lS4rakieycXrWvkqpitrL1BOtTpB8d+\nrIQd1Dq0851vTwFtKOGM+/AyZj3YFmPquLyjh+Y/f8gEOhl2ukbxaKNNMEswDgYD\nVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAge6hctPp8Ssm+\nTGXjjrrMd9qmboKo+htQUvaMtAEs1jkwCgYIKoZIzj0EAwIDRwAwRAIgdNm6ogr4\nh5IOGqgxvxKQIgcVotBWSE22ienKZMxaMsACICH02+7VWNGoegJIxh3uSbSxczUd\nkIq+MzhhkpPKGly7\n-----END -----\n"},"signature":{"type":"Buffer","data":[48,69,2,33,0,175,157,205,24,107,173,2,11,115,93,222,233,81,233,62,154,58,80,174,140,163,75,69,134,90,10,6,208,190,197,97,64,2,32,85,188,87,232,107,88,209,230,47,166,33,55,144,122,127,96,254,233,232,126,135,142,197,32,244,185,161,153,55,158,145,53]}}]}}}]}}}]},"metadata":{"metadata":[{"value":"","signatures":[{"signature_header":{"creator":{"Mspid":"OrdererMSP","IdBytes":"-----BEGIN -----\nMIICDjCCAbSgAwIBAgIRAL3LhCHP9JqZHZZ7b9ySDv4wCgYIKoZIzj0EAwIwaTEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xFDASBgNVBAoTC2V4YW1wbGUuY29tMRcwFQYDVQQDEw5jYS5leGFt\ncGxlLmNvbTAeFw0xNzA3MTUwMjA2MzZaFw0yNzA3MTMwMjA2MzZaMFkxCzAJBgNV\nBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNp\nc2NvMR0wGwYDVQQDExRvcmRlcmVyMS5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEG\nCCqGSM49AwEHA0IABJ03AFAenfTyKuUizftsgDoCSehL8Rq4P1aOZcWB9Vyc++wL\nVtLLRwY6KxsVXjWxWulB0ZTtB6eo87YZK+NTzrOjTTBLMA4GA1UdDwEB/wQEAwIH\ngDAMBgNVHRMBAf8EAjAAMCsGA1UdIwQkMCKAIK5UyPy5CEnmLHYxFr/X2clqaUsw\nbq/ZDXsldo5VCZFbMAoGCCqGSM49BAMCA0gAMEUCIQDJTrQshJZisDFc6P8dQk+6\n1g/mMk9Ca5O7NCtRkZVk2gIgN/hhNZUgrn9R2IKUDkTkJYJNXxufE+50XW/73GAU\n+VE=\n-----END -----\n"},"nonce":{"type":"Buffer","data":[221,219,25,77,4,161,236,90,80,83,195,131,16,249,199,42,225,136,101,48,237,211,172,31]}},"signature":{"type":"Buffer","data":[48,69,2,33,0,232,219,57,242,62,100,183,208,105,96,73,9,233,92,96,78,19,242,46,152,93,100,11,227,145,148,90,66,145,188,128,148,2,32,70,185,2,84,194,105,13,44,254,10,154,56,69,114,115,230,70,80,182,235,30,204,220,151,250,40,182,196,11,45,104,68]}}]},{"value":{"index":{"low":0,"high":0,"unsigned":true}},"signatures":[{"signature_header":{"creator":{"Mspid":"OrdererMSP","IdBytes":"-----BEGIN -----\nMIICDjCCAbSgAwIBAgIRAL3LhCHP9JqZHZZ7b9ySDv4wCgYIKoZIzj0EAwIwaTEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xFDASBgNVBAoTC2V4YW1wbGUuY29tMRcwFQYDVQQDEw5jYS5leGFt\ncGxlLmNvbTAeFw0xNzA3MTUwMjA2MzZaFw0yNzA3MTMwMjA2MzZaMFkxCzAJBgNV\nBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNp\nc2NvMR0wGwYDVQQDExRvcmRlcmVyMS5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEG\nCCqGSM49AwEHA0IABJ03AFAenfTyKuUizftsgDoCSehL8Rq4P1aOZcWB9Vyc++wL\nVtLLRwY6KxsVXjWxWulB0ZTtB6eo87YZK+NTzrOjTTBLMA4GA1UdDwEB/wQEAwIH\ngDAMBgNVHRMBAf8EAjAAMCsGA1UdIwQkMCKAIK5UyPy5CEnmLHYxFr/X2clqaUsw\nbq/ZDXsldo5VCZFbMAoGCCqGSM49BAMCA0gAMEUCIQDJTrQshJZisDFc6P8dQk+6\n1g/mMk9Ca5O7NCtRkZVk2gIgN/hhNZUgrn9R2IKUDkTkJYJNXxufE+50XW/73GAU\n+VE=\n-----END -----\n"},"nonce":{"type":"Buffer","data":[102,198,192,148,105,195,95,35,227,159,243,46,170,54,139,206,1,178,202,106,101,138,20,40]}},"signature":{"type":"Buffer","data":[48,68,2,32,103,165,68,221,214,173,63,247,51,103,89,78,203,4,88,195,138,195,24,208,187,42,18,130,85,77,113,53,21,236,98,58,2,32,69,74,193,231,116,52,159,94,196,191,0,46,249,45,15,78,164,60,74,242,92,200,149,185,113,241,175,7,13,200,228,142]}}]},[]]}}

Query on chaincode on target peers

http://localhost:8080/apis/channels/:channelName/chaincodes/:chaincodeName?peer=peer1&fcn=:fcn&args=:args

example:

http://localhost:8080/apis/channels/mychannel1/chaincodes/mycc?peer=peer1&fcn=get&args=%5B%22org2%22%5D

returns:

putsomerandomvalue-org2

Invoke transaction on chaincode on target peers

curl -s -X POST \
 http://localhost:8080/apis/channels/:channelName/chaincodes/:chaincodeName \
 -H "content-type: application/json" \
 -d '{
 "peers": ["127.0.0.1:7051", "127.0.0.1:8051"],
 "fcn":"put",
 "args":["org1","putsomerandomvalue-org1"]
}'

example:

curl -s -X POST \
 http://localhost:8080/apis/channels/mychannel1/chaincodes/mycc \
 -H "content-type: application/json" \
 -d '{
 "peers": ["127.0.0.1:7051", "127.0.0.1:8051"],
 "fcn":"put",
 "args":["org1","putsomerandomvalue-org1"]
}'


returns txid:

423d0a22c07cd577d6f7f32bd02cd7ed5989baa11b08abcc714077a3a7e9eefe

Instantiate chaincode on target peers

curl -s -X POST \
  http://localhost:8080/apis/channels/:channelName/chaincodes \
  -H "content-type: application/json" \
  -d '{
 "chaincodeName":"mycc",
 "chaincodeVersion":"v0",
 "functionName":"init",
 "args":[""]
}'

example:

curl -s -X POST \
  http://localhost:8080/apis/channels/mychannel1/chaincodes \
  -H "content-type: application/json" \
  -d '{
 "chaincodeName":"mycc",
 "chaincodeVersion":"v0",
 "functionName":"init",
 "args":[""]
}'

Install chaincode on target peers

example:

curl -s -X POST \
  http://localhost:8080/apis/chaincodes \
  -H "content-type: application/json" \
  -d '{
 "peers": ["127.0.0.1:7051","127.0.0.1:8051"],
 "chaincodeName":"mycc",
 "chaincodePath":"github.com/uniqueKeyValue",
 "chaincodeVersion":"v0"
}'

Join Channel

curl -s -X POST \
  http://localhost:8080/apis/channels/:channelName/peers \
  -H "content-type: application/json" \
  -d '{
 "peers": ["127.0.0.1:7051","127.0.0.1:8051"]
}'

example:

curl -s -X POST \
  http://localhost:8080/apis/channels/mychannel1/peers \
  -H "content-type: application/json" \
  -d '{
 "peers": ["127.0.0.1:7051","127.0.0.1:8051"]
}'

Create/Update Channel


example:

curl -s -X POST \
  http://localhost:8080/apis/channels \
  -H "content-type: application/json" \
  -d '{
 "channelName":"mychannel1",
 "channelConfigPath":"../artifacts/channel/mychannel1.tx",
 "configUpdate":false
}'

Courtesy: https://github.com/hyperledger/blockchain-explorer

How to Setup the Hyperledger Fabric-ca Client Setup on Ubuntu 16.04 - Part 3

noreply@blogger.com (Farhad) — Wed, 06 Dec 2017 11:02:00 +0000

How to Setup the Hyperledger Fabric-ca Client Setup on Ubuntu 16.04 - Part 3

This article is about the steps needed to setup your own CA Server and register/enroll new users into your database. The server provides the public/private key pair as a response to enrolling the user into the database. If you need help to configure the requirements to download Hyperledger, check out the first article in this three part tutorial series to learn Hyperledger. If you need help to set up your Hyperledger server check out the second article in this series.

Now, that we have our server setup, we want to enroll existing and register new clients to the database. Let’s move on to it.

Just as we build the fabric-ca-server command in the Fabric-CA directory, we need to do the same for the fabric-ca-client to access commands for the client side. Use the following command in the root directory of your fabric-ca cloned project:

make fabric-ca-client

You should see the output similar to the one mentioned below and should see a new executable in the bin directory of fabric-ca.

For this part of the tutorial, we use the FABRIC_CA_CLIENT_HOME variable. Please add the following lines to the end of .bashrc file and reload the file too. The lines are:

export FABRIC_CA_HOME=~/Documents/Fabric-CA
export FABRIC_CA_CLIENT_HOME=$FABRIC_CA_HOME/client

You can initialise the variable with any directory you feel like doing. But, we assume that you have already set your FABRIC_CA_CLIENT_HOME variable for the rest of the tutorial.

To check, whether your fabric-ca-client is accessible or not, just type:

fabric-ca-client

And you should see a similar output:

Now, we know that from our server configuration, we have an admin user already registered into the database since the start of the server. So, we will use that credentials to enroll our admin user first and retrieve the public/private key pair to be able to register new users afterwards.

We use the following command:

fabric-ca-client enroll -u “http://admin:adminpw@localhost:7054”

The “admin:adminpw” is actually a “username:password” pair which we need to send to localhost:7054, the default server url and port, our server listens to. If everything goes well, you should see the following output:

Now, that we have successfully enrolled the admin user, we have cert.pem (public key) and key.pem (private key) of the user. Also, as we were using this for the first time, we have the config file, fabric-ca-client-config.yaml, in the directory mentioned in the output.

Let us discuss some important fields in the fabric-ca-client-config.yaml file:

The “URL” field defines the default URL to connect to the server. It can be custom specified by the “-u” flag in the fabric-ca-client command.
The “TLS” section defines the tls configuration, required for secure connection to the server and ensure privacy over the internet. But, as we were using localhost in the system, there was no need to tls and so it was disabled by-default.
The“CSR” field is the “Certificate Signing Request”, which is sent to the server to sign the certificates with the provided details only. By-default, there are some values provided, but can be edited according to the needs.
The“Id” section defines the defails of a new user we want to register. This field eliminates the need to provide command line arguments as mentioned below in the tutorial. We use command line to ensure no error in the config file.
The “Enrollment” section as defined in the config file, is used to enroll any user with the appropriate details, stored in the server DB.

Now, we have to create a new user and register it. For that, we need to use the following command:

fabric-ca-client register -u “http://localhost:7054” --id.name “mlgblockchain” --id.secret “mlg” --id.type “client” --id.affiliation “org1.department1”

When you run this command, you should see the following output upon successful execution:

Now, we have registered our new user “mlgblockchain”, with the following values:

--id.name - The name of the user.
--id.secret - The password for the user to enroll.
--id.affiliation - The organization and department the user is affiliated to. Mainly to segregate the user permissions.
--id.type - The type of the user. We are using “client”, but a user can be peer, validator, auditor, ca, etc.

Now, that we have registered our new user, we need to enroll into the server to get the public / private keys for the user “mlgblockchain”.

So we use the following command:

fabric-ca-client enroll -u “http://mlgblockchain:mlg@localhost:7054”

If all goes well, you should see the following output:

So, upon successful enrollment of the user, you shall receive the keys in the directory mentioned in the output.

Congrats! Finally, you are able to setup your own CA Server for the enrollment and signing of new Users required for your application.

Courtesy: Akarsh Agarwal
Original Source : https://mlgblockchain.com/setup-hyperledger-client.html

How to Setup the Hyperledger Fabric-ca Server Setup on Ubuntu 16.04 - Part 2

noreply@blogger.com (Farhad) — Wed, 06 Dec 2017 10:53:00 +0000

How to Setup the Hyperledger Fabric-ca Server Setup on Ubuntu 16.04 - Part 2

The Hyperledger Fabric project by IBM provides an easy plug-n-play interface for the users to attach their custom Certificate Authority(CA) Server. This has been actively made possible in the newer version of Hyperledger Fabric v1.0 as opposed to v0.6. There is support for this functionality in older versions, but they have been made more easily integrated in the newer release.

The fabric-ca project can be downloaded from the official gerrit codebase using the following command. This will download the required files into your directory. The directory structure is important for the fabric-ca to work. The picture below is a sample of where to place the fabric-ca directory:

git clone https://gerrit.hyperledger.org/r/fabric-ca

To make the above screenshot more clear, the fabric-ca directory should be placed inside the GOPATH variable of your system. To set the GOPATH locally run the following command:

export GOPATH=~/Documents/Blockchain

The directory structure that follows the GOPATH is GOPATH -> src -> github.com -> hyperledger -> fabric-ca. It is recommended that you follow the same directory structure to avoid any errors that might arise during building or compiling the code.

Now, as we have downloaded the files into the required location, we need to build the fabric-ca server and add the path to the executable to have the command available across the system in the terminal. To build the fabric-ca server, go to the root directory of fabric-ca, i.e., inside the fabric-ca directory and run the following command and you should see the screenshow below.

make fabric-ca-server

When the above command finishes, the output should be similar to the one shown above. It might take from a few seconds to a minute so be patient. To check whether you have the executable or not, list the contents of the directory “bin” and there should be a new file, in a different color, which is the executable.

Now, that we have the executable, we need to be able to access it from anywhere in the system. To do this we need to append the directory of fabric-ca to the PATH variable in the .bashrc file. The command to edit the .bashrc file is:

sudo nano ~/.bashrc

Next, append the following line at the bottom of the file: export PATH=$PATH:~/Documents/Blockchain/src/github.com/hyperledger/fabric-ca/bin

Save the file and close it. Now, we need to refresh the variables to be able to access the fabric-ca command from anywhere. The command to do this is:

source ~/.bashrc

To check whether the fabric-ca-server command works or not, just type in the following command and you should see the output below returned to your terminal.

fabric-ca-server

If you see any other output from the one displayed here, maybe there is some error in the installation and you might want to revisit the starting of the tutorial again.

Please ensure that, this documentation is the basic installation of the Fabric-CA service. More tweaking and settings can be found under the section of Fabric-CA Setup, at the official documentation of Hyperledger Fabric.

Fabric-CA Server Setup

The Fabric-CA Server acts as our custom CA to register and enroll new users, as well as existing users into the database. The server sends the key pair, when trying to enroll an already registered user.

To get started, we set-up a new directory for our work environment, so as to not disturb the original files. To create a new directory you can name it whatever you like. Here is what I’ve done below:

For our server to save our files to the current directory, we need to set-up a new environment variable. Call this environment variable FABRIC_CA_SERVER_HOME to follow along with the tutorial. Set this variable to the current directory adding the following lines to the .bashrc file at the end of the file:

export FABRIC_CA_HOME=~/Documents/Fabric-CA 
export FABRIC_CA_SERVER_HOME=$FABRIC_CA_HOME/server

I assume that you have set your FABRIC_CA_SERVER_HOME as your current directory, for the rest of the Fabric-CA Server Setup.

We need some configuration files, but first we need a pair of keys for the server to ensure the client is able to contact the right server. We use the following commands to generate the public/private key pair. Here, ca-cert.pem is the public key and ca-key.pem is the private key.

Now that we have our private and public keypair, we run the following command to auto-initialise all the config files and auto-create the keys. In the command, the ‘-b “admin:adminpw” ‘ initialises our bootstrap user for the database. A user which will be used to login the first time we want to start using our system. Now, after you run the command, you shall see the following output:

fabric-ca-server init -b “admin:adminpw”

From the above output, you can make out that we have the keys and the configuration files auto-generated for us by the Fabric-CA. Also, we see another file, fabric-ca-server.db. This file stores all the users that are currently registered with the Fabric-CA server. This is by-default a SQLITE3 database, however you are able to configure the fabric-ca-server-config.yaml file to use either a PostGreSQL or a Mysql database instead.

We have configured all of our files now, but it is important to understand the various fields in the config file before we run our first server. These fields are important and the documentation is given in the config file. The explanation of each field is below.

Config File Variables

The “port” field defines on which port to run the server. By-default the port is 7054.
The “debug” field is for logging while working in development environment.
If your server is run on a HTTPS protocol, the “tls” should be enabled, as we are working on localhost, the default value is always “false”.
We define the keys to be used by the server for signing the client keys, in the “certfile” and “keyfile” section. This variable is mainly used, when we know that the CA and the server are two different entities, but here, the server is itself the CA, so we put the server’s keys in the ca’s keys.
Max_enrollments defines how many users can be enrolled using the same password. If is set to 0, it can be infinitely done, but suppose it is set to 1, it will allow a user to enroll only once.
The next section defines the database we are going to use. By-default, Hyperledger Fabric-CA provides support for 3 types of databases, namely, Sqlite, Postgres and Mysql. You can configure any of the three, but default configuration is “sqlite3” for this tutorial. More can be found about configuring the other two, on the documentation of Hyperledger Fabric.
The LDAP section we are going to skip and keep the value to the default as it is out of the scope of this tutorial.
The affiliations section defines the organizations and departments with which your user is going to be associated to classfiy different types of users.
Signing section is used to define what is the time period for the validity of the client’s signed certificates and what are the other usages of server certificate used in the configuration.
“CSR” section is used to create “Certificate Signing Request” required to generate CA certificates, so as to put in the default details.
The last section we have is the “crypto”, which defines what type of algorithm the server should use and other cryptographic terms. This is also left as it is.

Now, that we have all the files required, our server is ready to be initiated. Use the command below to start your server.

fabric-ca-server start -b “admin:adminpw”

If everything goes right, you should see the following output from your terminal.

Now, our localhost Fabric-CA Server is up and running. Congrats for achieving this milestone. Next we shall move onto setting up the Fabric-CA Client, to enable it to communicate it with our localhost.

Courtesy: Akarsh Agarwal
Original Source : https://mlgblockchain.com/setup-hyperledger-fabric.html

Install Hyperledger Fabric on Ubuntu 16 and execute Deploy, Invoke and Query - Part I

noreply@blogger.com (Farhad) — Wed, 06 Dec 2017 10:49:00 +0000

Install Hyperledger Fabric on Ubuntu 16 and execute Deploy, Invoke and Query - Part I

There is an entire library of Blockchain APIs which you can select according to the needs that suffice your application. Some libraries are open-sourced and some are private. For examples, IBM’s Hyperledger Fabric Project, Ethereum, OpenChain are few of the open sourced models which are popular in the market today.

This tutorial is to help you setup your development environment for a blockchain application using the IBM-Hyperledger Fabric API.

In this tutorial, we will be setting Hyperledger Fabric v1.0 on Ubuntu 16.04 on a localhost server. This tutorial can be applied to Ubuntu 14.04 too, but would involve certain changes to the commands due to the difference in the OS.

This tutorial is broken into 2 parts so that it is easier for you to understand and follow through the steps without making the article too long. The 1st part focuses on installing the prerequisites for the API and the 2nd part will focus on installing and running of Hyperledger API itself.

Prerequesites

Go Language v1.8.x
Docker Engine

Go Language v1.8.x

Go Language has been developed by Google and the IBM Hyperledger Fabric API uses Go for compiling and building. Go integrates the properties of C++ and Python into one language. It has fast runtime because it is a compiled language, similar to C++, as compared to an interpreted language like Python. It is also written in a similar way to Python so it benefits from have having a simpler syntax to C++. So, we get the faster speed and easiness of syntax in one package, Go.

To install the Go Language, we need to download the package from the official Go Download Page. To follow along with this tutorial, select the option in the Linux section, as described in the screenshot below (xx.tar.gz package).

Once the package is downloaded, we need to extract it and move it to /usr/local/ directory, so that our application can access it and more importantly, the Go files are situated at a safe place, where you don’t accidently delete them.

To extract the Go package, use the command below.

sudo mv go /usr/local/

When you see the directory (/usr/local/), you should now see that there is a new folder named “go”, in your directory. This shows that the go files have been correctly placed in the desired location. Here is a screenshot for you to verify and check whether you have something similar to this or not.

Now that we have the Go files in the correct place, we want to configure the terminal to locate the files when we want to execute any Go command. We need to include it into our environment variables. For this, we need to edit the ~/.bashrc file of the system, which keeps track of the environment variables of your system. To edit that file, use the following command.

sudo nano ~/.bashrc

Include the following lines at the end of the file

#GO VARIABLES
export GOROOT=/usr/local/go
export PATH=$PATH:$GOROOT/bin
#END GO VARIABLES

The PATH variable is the environment Path variable. The GOROOT variable defines where are your Go files situated in the system.

To reload the environment variables, we use the following command.

source ~/.bashrc

This command gives no output, but just simply reloads all the environment variable in background. Now, we can check the installation of Go in our terminal by typing:

go

If the installation was successful, you should see the following output.

If you see any other output except this, maybe you might have done some mistake. Please go through the steps again above.

Now we have installed the Go language on the host machine and we are halfway through setup of prerequisites for the Hyperledger API, Congrats!.

Docker Engine

Docker is the container where you will be running your instances which makes sure that the blockchain application you run is available. Consider docker as a Virtual Machine Box, which runs images which have specific functionalities, just like Windows and Ubuntu, however each Docker image is smaller in size as compared to an Operating Systems. Each docker images will run a service associated with the Hyperledger network in your localhost. We shall cover two such services absolutely required by the Blockchain Network to run your application, in the next part of the tutorial. We will see how to install docker in this part.

We need to install docker on your system to be able to understand the beauty that lies within. So, let’s get started!

To install docker through CLI or Terminal, we will need to install two packages: Docker-engine and Docker-compose. Docker-engine is like the base package which makes all the necessary files available for the docker container to run properly. Docker-compose configures your docker images according to the specific configuration you provide, which will enable the Blockchain service.

To install docker-engine, enter the following command in the terminal.

sudo apt-get install -y docker-engine

Your output will differ from me as I have the Docker-Engine already installed on my system. But there is no error in the console, which ensures that it has been installed correctly. After you run the above command, docker should be installed on your system.

Now, we need to enable the docker service at startup of the system. We write the following commands:

To start the docker service:

sudo service docker start

If all goes well, there will be no output. If you get an error, please consider re-installing the docker-engine again.

To enable the docker to start at startup of the system, we use the following command:

sudo systemctl enable docker

If all goes well, your output should match with the screenshot displayed above. Now, each time you reboot your system, your docker container will be reloaded automatically.

To check if the docker service is running, just type:

docker

And you should get a similar output as below.

If you get anything else, please consider re-installing the docker-engine.

Now, the second part of docker-engine is the docker-compose function, which is needed to configure the docker images you are calling.

For that, we use python’s pip. You can use the following command to install docker-compose:

sudo pip install docker-compose

The installation should complete without any red text at the bottom. This makes sure that we have our docker-engine and docker-compose properly installed in our system. But to work with the docker images, you need to add your user to the docker group, which was created during installation of docker-engine as a part of setup.

sudo usermod -aG docker $(whoami)

This command will provide no output. If any output is displayed, maybe there is something wrong with the command you just typed into your console. Please check if you have written the same line of code. After successfully completing, this adds your current logged in user to the docker group, which will enable you to run docker images.

So, at this point, we have setup our two essential packages, Go Language and Docker-Engine, which are required to run the Hyperledger Fabric API. The setup and installation part of Hyperledger Fabric API will be presented in the next part of the tutorial.

If you have any doubts or errors, please email hello@mlgblockchain.com and we shall get back to you as soon as possible, with a possible solution.

MLG Blockchain is a blockchain development and consulting firm based in Toronto that is focused on building next generation applications using blockchain and smart contract technology. View all our blockchain development tutorials at www.mlgblockchain.com/learn.html.

Courtesy: Akarsh Agarwal
Original Source : https://mlgblockchain.com/hyperledger-pre.html

	apt-get update
	aptitude install xfonts-base xfonts-75dpi fontconfig xvfb
	mkdir ~/src/wkhtmltopdf -p
	cd ~/src/wkhtmltopdf
	wget https://bitbucket.org/wkhtmltopdf/wkhtmltopdf/downloads/wkhtmltox-0.13.0-alpha-7b36694_linux-jessie-amd64.deb
	dpkg -i wkhtmltox-0.13.0-alpha-7b36694_linux-jessie-amd64.deb
	echo 'xvfb-run --server-args="-screen 0, 1024x768x24" /usr/local/bin/wkhtmltopdf $*' > /usr/bin/wkhtmltopdf.sh
	chmod a+rx /usr/bin/wkhtmltopdf.sh
	ln -s /usr/bin/wkhtmltopdf.sh /usr/local/sbin/wkhtmltopdf
	/usr/local/sbin/wkhtmltopdf https://www.google.fr output.pdf

	apt-get update
	apt-get install wkhtmltopdf xvfb xauth xfonts-base xfonts-75dpi fontconfig
	echo 'xvfb-run --server-args="-screen 0, 1024x768x24" /usr/bin/wkhtmltopdf $*' > /usr/bin/wkhtmltopdf.sh
	chmod a+rx /usr/bin/wkhtmltopdf.sh
	ln -s /usr/bin/wkhtmltopdf.sh /usr/local/sbin/wkhtmltopdf
	/usr/local/sbin/wkhtmltopdf https://www.google.fr output.pdf

Do Something Different...

Deploying a strongSwan IKEv2 VPN Server for Native Android 12+ Connectivity

How to Build an IKEv2 VPN Server for Android (Ubuntu 22.04)

Step 1: Install Dependencies

Step 2: Generate PKI Certificates

Step 3: Configure strongSwan (ipsec.conf)

Step 4: Set Credentials (ipsec.secrets)

Step 5: Networking & Firewall

Setting Up MariaDB MaxScale Binlog Proxy for backup/failover

Setting Up MariaDB MaxScale Binlog Proxy

Step 1: Install MariaDB MaxScale

Step 2: Configure MaxScale as a Binlog Proxy

Step 3: Set Up Users on the Primary Database

Step 4: Start and Enable MaxScale

Step 5: Configure Replica Servers to Use MaxScale

Deploying a laravel app using nginx alias

Get wifi password easily from a windows PC

Setup a Multi-Protocol VPN Server Using SoftEther on Centos7

Introduction

What is SoftEther

Step 1: Create a Virtual Server

Step 2: Update your Server Software

Step 3: Download SoftEther

Here’s how to do it using lynx:

Step 4: Install and Configure SoftEther

Step 5: Change Admin Password

Step 6: Create A Virtual Hub

Step 7: Enable SecureNAT

Step 8: Create and Manage Users

Step 9: Setup L2TP/IPSec

Step 10: Setup SSTP/OpenVPN

Step 11: Connecting to SoftEther VPN Server (Client Configuration)

Configure Galera Cluster with Mariadb 10.3 on Centos7 with HAproxy load balancer

Introduction

Prerequisites

Step 1 — Adding the MariaDB Repositories to All Servers

Step 2 — Installing MariaDB on All Servers

Step 3 — Configuring the First Node

Step 4 — Configuring the Remaining Nodes

Step 5 — Opening the Firewall on Every Server

Step 6 — Creating a SELinux Policy

Step 7 — Starting the Cluster

Stop MariaDB on All Three Servers

Bring Up the First Node

Bring Up the Second Node

Bring Up the Third Node

Step 8 — Testing Replication

Write to the First Node

Read and Write on the Second Node

Read and Write on the Third Node

Read on the First Node

Conclusion

Step 2 - Install and Configure HAProxy

Step 3 - Testing HAProxy and MariaDB

A. Replication testing

B. Access the MariaDB Server trough HAProxy

C. Login to the HAProxy Web-Gui

Setup Keycloak Server on Debian 11

Using Fail2Ban to prevent/limit bot attack to wordpress wp-login.php [Centos7]

Daily mysql databse backup with datetime stamp with cronjob

Creating MySQL Backup Script

Specific NodeJs version install with NVM

Install Node.js and npm on Debian

Install Node.js from NodeSource Repository

Install Node.js and npm using nvm

Uninstall Node.js and npm

Conclusion

Install wkhtmltopdf from source

Install wkhtmltopdf on Debian 8, 9

Prevent SSH Brute Force Attack by Automatically Blacklisted

Bandwidth Limiting Big Files Download - Mikrotik

WSO2Torial: Setting up WSO2 with a valid SSL certificate

How do Certificates work?

Creating and configuring a new keystore

Give permission to a SSH user only to a specific directory and block terminal access !!

SWAP: Allocate swap space in Centos7

Introduction

Prerequisites

Check the System for Swap Information

Check Available Storage Space