For those of you who didn’t know, OwnCloud is a free and open-source software which enables you to create a private “file-hosting” cloud. OwnCloud is similar to DropBox service with the diference of being free to download and install on your private server. Owncloud made by PHP and backend database MySQL (MariaDB), SQLLite or PostgreSQL. OwnCloud also enables you to easily view and sync address book, calendar events, tasks and bookmarks. You can access it via the good looking and easy to use web interface or install OwnCloud client on your Desktop or Laptop machine (supports Linux, Windows and Mac OSX).

This article assumes you have at least basic knowledge of linux, know how to use the shell, and most importantly, you host your site on your own VPS. The installation is quite simple. I will show you through the step by step installation OwnCloud 8 on Ubuntu 14.04.

Install OwnCloud 8 on Ubuntu 14.04

Step 1. First of all log in to your server as root and make sure that all packages are up to date.



apt-get update

Apt-get upgrade

Step 2. Instal Apache web server on your Ubuntu 14.04 VPS if it is not already installed.


apt-get install apache2

Step 3. Next, install PHP on your server.


apt-get install php5 php5-mysql

Once the installation is done add the following PHP modules required by OwnCloud:


apt-get install php5-gd php5-json php5-curl php5-intl php5-mcrypt php5-imagick

Step 4. Install MySQL database server.


apt-get install mysql-server

By default, MySQL is not hardened. You can secure MySQL using the mysql_secure_installation script. you should read and below each steps carefully which will set root password, remove anonymous users, disallow remote root login, and remove the test database and access to secure MySQL.



Step 5. Create a new MySQL database for OwnCloud using the following commands.









#mysql -u root -p

Enter password:

mysql> CREATE USER ‘ownclouduser’@’localhost’ IDENTIFIED BY ‘YOURPASSWORD’;

mysql> CREATE DATABASE ownclouddb;

mysql> GRANT ALL ON ownclouddb.* TO ‘ownclouduser’@’localhost’;


mysql> exit

Step 6. Installing Owncloud 8.

First we will need to download the latest stable release of OwnCloud on your server (at the time version 8.2.2).



tar -xvf owncloud-8.2.2.tar.bz2 -C /var/www/html/

Set the directory permissions:


chown www-data:www-data -R /var/www/html/owncloud/

Step 7. Configuring Apache for OwnCloud.

While configuring Apache web server, it is recommended that you to enable .htaccess to get a enhanced security features, by default .htaccess is disabled in Apache server. To enable it, open your virtual host file and make AllowOverride is set to All.For example, here i used external config file instead of modifying main file.












### nano /etc/apache2/sites-available/owncloud.conf

<IfModule mod_alias.c>

Alias /owncloud /var/www/html/owncloud


<Directory “/var/www/html/owncloud”>

Options Indexes FollowSymLinks

AllowOverride All

Order allow,deny

allow from all


Remember to restart all services related to Apache server.


service apache2 restart

Step 8. Access OwnCloud application.

Navigate to http://your-domain.com/ or http://your-ip-address and follow the easy instructions. Enter username and password for the administrator user account, click on the ‘Advanced options’ hyperlink and enter the data directory (or leave the default setting), then enter database username, database password, database name, host (localhost) and click ‘Finish setup’


Change the data directory as ” /var/ownclouddata ” to restrict public access of all user data

mkdir /var/ownclouddata

chown -R www-data:www-data /var/ownclouddata

if you faced any issue while configure this OwnCloud initial setup drop all tables in the given data base and

complete the setup again.

Two-step verification (also known as Two-factor authentication, abbreviated to TFA) is a process involving two stages to verify the identity of an entity trying to access services in a computer or in a network. This is a special case of a multi-factor authentication which might involve only one of the three authentication factors (a knowledge factor, a possession factor, and an inheritance factor) for both steps. If each step involves a different authentication factor then the two-step verification is additionally two-factor authentication.
Link to original post: http://www.blackmoreops.com/2014/06/26/securing-ssh-two-factor-authentication-using-google-authenticator/

Google’s two-step verification process

Google was one of the first Internet companies to introduce a two-step verification process. To access a Google service using the two-step verification process, a user has to go through the following two stages:

The first step is to log in using the username and password. This is an application of the knowledge factor.
The implementation of the second step requires a mobile phone or the Google Authenticator application, which is an application of the possession factor.

If the user opts to use a mobile phone, he/she has to register his/her phone number with Google. When one attempts to authenticate with username and password, Google will send via SMS a new, unique code to the phone. Receiving the SMS demonstrates that the user has the phone (or, in the case of GSM like networks the appropriate SIM chip).

If the user opts to use the Google Authenticator (or another supported code generator application), he/she simply opens the application, which generates a new code every 30 seconds. This code is to be entered to complete the log in process. As a backup option in case the registered mobile phone or device running Google Authenticator is lost, stolen, or otherwise unavailable, the user can print a set of static single-use backup codes (also the knowledge factor) and store them in a safe place.

The following are some other sites which offer two-step verification service:

  1. Amazon Web Services,
  2. ANX
  3. App.net
  4. Apple ID
  5. Authy
  6. Battle.net
  7. Bitstamp
  8. Blockchain.info
  9. Box
  10. Dropbox
  11. eBay
  12. Etrade
  13. Evernote
  14. Facebook
  15. GitHub
  16. GoDaddy
  17. HootSuite
  18. Lastpass
  19. LinkedIn
  20. LocalBitcoins
  21. Microsoft
  22. MongoLab
  23. Namecheap
  24. PayPal
  25. SocialFlow
  26. timetotrade
  27. Tumblr
  28. Twitter
  29. Viaduct
  30. WordPress
  31. Yahoo! Mail
  32. innoview.gr
  33. zoho

Google Authenticator

Google Authenticator implements TOTP security tokens from RFC6238 in mobile apps made by Google, sometimes branded “two-step authentication”. The Authenticator provides a six digit one-time password users must provide in addition to their username and password to log into Google services or other sites. The Authenticator can also generate codes for third party applications, such as password managers or file hosting services. Some versions of the software are open source.
[Source: WikiPedia]

14 - Securing SSH with two factor authentication using Google Authenticator - blackMORE Ops

Note: Google Authenticator doesn’t “call home” to Google — all the work happens on your SSH server and your phone. Google Authenticator is a open-source software, that means you can check the codes yourself. I guess after what happened with openSSL, that’s not a bad idea after all.

In this article I will demonstrate how to secure SSH by setting up Two Factor Authentication (TFA) with Google Authenticator for the following Linux operating systems:

  1. Debian
  2. Ubuntu
  3. Linux Mint
  4. Kali Linux
  5. Red Hat
  6. CentOS
  7. Fedora

Google Authenticator can be used in the following smartphones:

  1. Android,
  2. iOS and
  3. Blackberry.

I am not too sure if you can use this on a Windows Based phone (i.e. new Nokia phones or Windows Mobiles devices). Feel free to try and report back.

App Download Links as follows:

  1. Android: https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en
  2. iOS: https://itunes.apple.com/au/app/google-authenticator/id388497605?mt=8
  3. Blackberry: http://www.google.com/mobile/other

More detailed per device install instructions can be found on this page:

The implementation is exactly same except for some package name differences. So you can implement this in any Linux Operating System that uses these packages.


Followings are the requirements for using Google Authenticator on your system:

  1. A PC running Linux
  2. A smartphone
  3. A running SSH server on your machine.

In case you don’t have SSH server running, just follow this guide to install openSSH server.

Step 1: Install dependencies for Google Authenticator Module

You need to have either root or sudo privileges on the machine where you want to secure SSH by enabling Two Factor Authention using Google Authenticator. Login to your machine and use the following commands to install required dependency packages:

On Debian, Kali, Ubuntu, Linux Mint (they all are Debian based system that uses aptitude as package manager i.e. apt-get/aptitude)

apt-get install libpam0g-dev

1 - Install dependencies for Google Authenticator PAM module - blackMORE Ops

On Red Hat, CentOS and Fedora (they all are RedHat based where you use yum as the package manager):

yum install pam-devel

That’s it. That should install the necessary dependencies on your system. In case you have a very restricted system where you dont have GCC, make and wget, you can install them using the following command(s):

yum install make gcc wget
apt-get install make gcc wget

Step 2: Download Google Authenticator Module

Google Authenticator is available on GoogleCode website.

Link: https://code.google.com/p/google-authenticator/

You can just copy paste the codes below to download and extract Google Authenticator codes. I personally use Kali Linux, that means I am always logged in as root user, if you’re using any of the other Linux distributions like Debian, Ubuntu, Linux Mint, Red Hat, CentOS or Fedora where you don’t usually login as root user, then you should choose your own directory to download and extract these codes.

To download Source code of the Google Authenticator PAM library module use the following command:

root@kali:~# wget http://google-authenticator.googlecode.com/files/libpam-google-authenticator-1.0-source.tar.bz2

At the time of writing this article, v1.0 was available.

2 - Download Google Authenticator PAM module from GoogleCode - blackMORE Ops

Now extract your tarball:

root@kali:~# tar -xvf libpam-google-authenticator-1.0-source.tar.bz2

Change directory to the extracted folder:

root@kali:~# cd libpam-google-authenticator-1.0/

3 - Extract Google Authenticator PAM module from GoogleCode - blackMORE Ops

Step 3: Compile and Install Google Authenticator PAM module

So far we’ve installed dependencies, downloaded and extracted Google Authenticator PAM module. Now we need to compile the codes and install compiled software on our system.
use the following command to compile your downloaded source codes:

root@kali:~/libpam-google-authenticator-1.0# make

4 - Compile extracted Google Authenticator PAM module from GoogleCode - blackMORE Ops

Now install Google Authenticator PAM module on your system:

root@kali:~/libpam-google-authenticator-1.0# make install

5 - Install compiled Google Authenticator PAM module from GoogleCode - blackMORE Ops

Step 4: Run and configure Google Authenticator

Just run Google Authenticator PAM module from command line to configure it for your system:

Run Google Authenticator PAM module using the following command:

root@kali:~/libpam-google-authenticator-1.0# google-authenticator

It should present you with bunch of question where you get to choose Y or N . Let’s have a quick look at those questions and the outputs.

Do you want authentication tokens to be time-based (y/n) y
Your new secret key is: WKHM6UVJNTPYSPTQ
Your verification code is 434260
Your emergency scratch codes are:

So on your first question, you get a secret key, Your new secret key is: WKHM6UVJNTPYSPTQ and 5 emergency scratch codes. You use the emergency key on your mobile so that you can get the correct verification code next time you login. Emergency codes are used when you’ve lost your mobile.
Next it asks you if you want to use this for your root account? Me being root users, I’ve chosen Yes.

Do you want me to update your "/root/.google_authenticator" file (y/n) y

Next up, it asks you if you want to disallow multiple uses of the same verification code. Unless you have a good reason not to, choose Yes.

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

Next part is time based login. From the point of getting the code on your mobile to typing in to your login prompt, 30 seconds should be more than enough. If you’r time sync is bad on your system or you’ve giving the code to someone over phone or you are a VERY slow keyboard warrior, I see no reason to change it. Select Yes here.

By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) y

Last up, well, of course we want to enable rate-limiting, by enabling this, you ensure that only 3 login attempts every 30s can be made.

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

This finishes your initial setup for Google Authenticator PAM module. Now we need to configure PAM and SSH to actually use this technique. This is really awesome.

6 - Configure google-authenticator PAM module for the first time - blackMORE Ops

Note: Leave this terminal window open (DO NOT CLOSE). We need the codes for next steps.

Step 5: Configure SSH to use Google Authenticator PAM Module

Open your PAM configuration file /etc/pam.d/sshd

root@kali:~# vi /etc/pam.d/sshd

and add the following line:

auth       required     pam_google_authenticator.so

7 - Configure SSHD PAM to use Google Authenticator PAM Module - blackMORE Ops

Next up, open your SSH configuration file /etc/ssh/sshd_config

root@kali:~# vi /etc/ssh/sshd_config

and modify the line containing ChallengeResponseAuthentication no:

ChallengeResponseAuthentication no
(change it to)
ChallengeResponseAuthentication yes

8 - Configure sshd_config PAM to use Google Authenticator PAM Module - blackMORE Ops

To have these changes take effect, restart SSH server:

service ssh restart
service sshd restart
/etc/init.d/ssh restart
/etc/init.d/sshd restart

Why 4 commands? Depending on your Linux distribution, some refers SSH Daemon as SSHD, some as SSH, some got service module installed, some requires you to go into /etc/init.d folder and restart SSH service manually.

For GUI Authentication:

Finally, add the following line to /etc/pam.d/gdm-password file:

auth required pam_google_authenticator.so

Save and close the file. On your next login, you should see a prompt for a verification code:

Fig.04: Google Authenticator code to protect Linux desktop login

Fig.04: Google Authenticator code to protect Linux desktop login

Step 6: Configure your SmartPhone for Google Authenticator App

Like I said before, Google Authenticator can be used in the following smartphones:

  1. Android: https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en
  2. iOS: https://itunes.apple.com/au/app/google-authenticator/id388497605?mt=8
  3. Blackberry: http://www.google.com/mobile/other

More detailed per device install instructions can be found on this page:

Assuming you managed to install the App properly, Launch your Google Authenticator app in your SmartPhone.

From Menu select Set up account

9 - Configure SMARTPhone to use Google Authenticator - blackMORE Ops

Step 6.1: Google Authenticator Setup Account

Remember the secret key you got when you initialized Google-Authenticator PAM module on your computer? I hope you still got that window open. Select Enter provided key.

10 - Select Enter provided key on SMARTPhone to use Google Authenticator - blackMORE Ops

Next window you give it a name (something you can remember or relates to your workstation .. i.e. Home Workstation or My SuperAwesome LinuxBox … I’m going to use blackMORE Ops as the name.

Type in your Secret Key on the next field and click on Add button.

11 - Manually enter name and secret key on SMARTPhone to use Google Authenticator - blackMORE Ops

Once it’s added it will generate a one time verification code (pin number) that will keep changing every 30 seconds.

Step 7: Login to your computer via SSH

Because I am doing all these in the same computer I will just login to localhost (IP: If you got 2 or more machines or VirtualBox/VMWare machines then you can try to login from a different one. One thing to note, you MUST have SSH server running.

In case you don’t have SSH server running, just follow this guide to install openSSH server.

So we type in the following command: (this is where you need to find out your SSH server’s IP address, I’ve shown using localhost or IP but this can be anything from an IP, FQDN or Domain name.)

root@kali:~# ssh

and immediately you see a prompt asking for Verification code. This is your Google Authenticator code that you get from your Google Authenticator Mobile App.

12 - Verification Key on SMARTPhone to use Google Authenticator - blackMORE Ops

Type in the numbers from your SmartPhones Google Authenticator App and then it will prompt your for your password. Type in your password to login now.

13 - Securely SSH and enter Google Authenticator Verification Key and password to login to SSH - blackMORE Ops

If you failed to type in the Verification code within 30 seconds, you have to try the next code shown on your SmartPhones Google Authenticator App. Awesome? Wouldn’t you agree?

Alternatives to Google Authenticator SmartPhone App:

In case you don’t own a SmartPhone or don’t want to use any, you can use the following add-on on your FireFox or IceWeasel browser:

FireFox/IceWeasel App: GAuth Authenticator https://marketplace.firefox.com/app/gauth-authenticator/

15 - Secure SSH with two factor authentication using Google Authenticator from FireFox- blackMORE Ops

Interesting Fact:


Got a response from the dev behind the Google Authenticator add-on for Chrome, Gerard Braad, who explained that Google have taken it down but gave no explanation as to why even after being asked several times.

The Firefox version is still available though and work great. Hopefully he may look into the issue with the Chrome version and re-submit.

Here is the FF version for those wishing to use it:



How about that?

[ Source: https://productforums.google.com/forum/#!topic/chrome/P9rTLaeyHjg ]


Securing SSH with two factor authentication using Google Authenticator is possibly the best security model you can out there for free. You can always restrict SSH by IP, change port, rate-limit and do all sorts of crazy stuffs. But those who wants to open SSH to the outside world and implement all these extra security models (i.e. Brute-force detection etc.) have to constantly worry about the fact that who is trying is and what you’ve missed while securing your system. Securing SSH with two factor authentication using Google Authenticator possibly relieves you from that worry and you stop getting emails in the middle of the night saying someone tried to login via SSH X amount of times.

Source from: https://www.linux.com/community/blogs/133-general-linux/783135-securing-ssh-with-two-factor-authentication-using-google-authenticato


I searched so many sites but the following method worked perfectly i have write this for help other who are looking  for this replication features:


PostgreSQL is a great advanced open source database. It offers many features, one of them being database replication. PostgreSQL 9.4 offers many different solutions to the replication problems, each one of them having it’s number of up’s and down’s. In the end it is up to the system or database administrator to decide which solution is best for specific scenario.

In the following post i decided to present how to configure PostgreSQL synchronous streaming database replication. Follow the steps closely and by the end of this tutorial you will have a working master/standby synchronous PostgreSQL replication. The benefit of a synchronous PostgreSQL replication over an asynchronous is that in case of master PostgreSQL database server failure you are sure you did not lose any data. The database client connected to the master PostgreSQL database gets a success message only once the data is written to both, master and standby PostgreSQL database server therefore there is no chance of loosing valuable data in the process.

Please note that the master/standby configuration actually means that the master server is in read/write mode while the standby server is in read-only mode. The read-only mode can however still be useful for reporting or similar activity.

Configure PostgreSQL Synchronous Streaming Database Replication

1. Install and Initialize PostgreSQL 9.4

To start configuring PostgreSQL Synchronous Streaming Database Replication i assume you have successfully installed and initialized PostgreSQL 9.4 on both linux servers you would like to use.

You can follow my posts on “Install PostgreSQL 9.3 on CentOS 6” or “Install PostgreSQL 9.4 on CentOS 7” if you need any help.


Stop firewall first.

/etc/init.d/iptables stop

2. Create PostgreSQL Replication Role

For the PostgreSQL Synchronous Streaming Database Replication to work, the standby instance connects to the master instance using a database user with replication privileges. Therefore we need to create a role and allow it to be used for replication purposes. Do this on the master instance.

Connect to master PostgreSQL server via “psql” and issue the following command:

postgres=# CREATE ROLE replication WITH REPLICATION PASSWORD 'password' LOGIN;

3. PostgreSQL Listen on IP Address

By default PostgreSQL only listens on “localhost” therefore denying outside connections to the database server. Firstly we must make the PostgreSQL database server to listen on desired IP address, which can be reconfigured in “/var/lib/pgsql/9.4/data/postgresql.conf” configuration file. Do this on the master instance.

Find the following line:

#listen_addresses = 'localhost'

Uncomment it and change to the desired IP address as follows:

listen_addresses = ''

Be sure to restart PostgreSQL service for changes to take effect.

4. Allow Replication Connection

You also need to allow connections from the PostgreSQL standby instance using the newly created replication role. You can configure this in “/var/lib/pgsql/9.4/data/pg_hba.conf” configuration file. Do this on the master instance.

Append the following lines at the bottom of configuration file – change the IP address with the one of your standby PostgreSQL server instance:

host replication replication trust

Note that by applying the “trust” for “replication” user from slave IP address “” this will allow connection to master PostgreSQL instance without password authentication.

Be sure to restart PostgreSQL service for changes to take effect.

5. Configure Streaming Parameters on Master

You need to edit “/var/lib/pgsql/9.4/data/postgresql.conf” configuration file and change some parameters accordingly to configure the PostgreSQL streaming replication. Do this on the master instance.

Find the following parameters in “postgresql.conf” and configure them as follows (uncomment if required):


wal_level = hot_standby # This sets slave server in read-only mode
fsync = on # Force synchronization
synchronous_commit = on # Enable synchronous commit
wal_sync_method = open_sync # Write WAL files with open() option O_SYNC


max_wal_senders = 1 # Max number of WAL senders - one slave, one sender
synchronous_standby_names = 'slave_node1' # Make this up, but remember it, will be used on slave instance configuration file

6. Start and Stop Master PostgreSQL

Once “postgresql.conf” file was reconfigured for “hot_standby” we need to start it to write out WAL logs with this configuration enabled. Once the master PostgreSQL has successfully started you can turn it off again.

7. Sync Data – Master to Slave

While both PostgreSQL instances are down, use rsync or some other tool to copy all of the contents in folder “/var/lib/pgsql/” from master PostgreSQL instance to slave PostgreSQL instance.

Skip the “/var/lib/pgsql/9.4/data/postgresql.conf” and “/var/lib/pgsql/9.4/data/pg_hba.conf” configuration files:

[root@node-1 /]# rsync -avr --exclude postgresql.conf --exclude pg_hba.conf /var/lib/pgsql/

8. Configure Streaming Parameters on Slave

Your PostgreSQL Synchronous Streaming Database Replication is almost up and running. Now you just need to open up the “/var/lib/pgsql/9.4/data/postgresql.conf” configuration file and apply the following change:

hot_standby = on
hot_standby_feedback = on

Create a new PostgreSQL slave instance specific configuration file “/var/lib/pgsql/recovery.conf”. Insert the following lines to “recovery.conf” file:

standby_mode = 'on'
primary_conninfo = 'host= port=5432 user=replication application_name=slave_node1'

The “recovery.conf” file provides information required for successful slave PostgreSQL connection to master instance. Note that IP address of the master instance must be changed accordingly along with the port number. Also the “application_name” is the “synchronous_standby_names” parameter configured on master PostgreSQL instance.

Change the owner of “/var/lib/pgsql/recovery.conf” to “postgres” user and make it rw for owner only:

[root@node-2 /]# chown postgres:postgres /var/lib/pgsql/9.4/data/recovery.conf
[root@node-2 /]# chmod 600 /var/lib/pgsql/9.4/data/recovery.conf

9. Start Slave PostgreSQL

Start slave PostgreSQL instance and check if the recovering process is up and running:

[root@node-2 /]# service postgresql-9.4 start
Redirecting to /bin/systemctl start postgresql-9.4.service
[root@node-2 /]# ps auxf |grep postgres
root 6692 0.0 0.1 112640 984 pts/0 S+ 15:13 0:00 _ grep --color=auto postgres
postgres 6679 0.1 2.0 337480 15212 ? S 15:13 0:00 /usr/pgsql-9.4/bin/postgres -D /var/lib/pgsql/9.4/data
postgres 6680 0.0 0.1 192596 1364 ? Ss 15:13 0:00 _ postgres: logger process 
postgres 6681 0.0 0.2 337596 2240 ? Ss 15:13 0:00 _ postgres: startup process recovering 000000010000000000000001
postgres 6682 0.0 0.2 337480 1676 ? Ss 15:13 0:00 _ postgres: checkpointer process 
postgres 6683 0.0 0.2 337480 1684 ? Ss 15:13 0:00 _ postgres: writer process 
postgres 6684 0.0 0.2 192724 1576 ? Ss 15:13 0:00 _ postgres: stats collector process

10. Start Master PostgreSQL

Start master PostgreSQL instance and check if the WAL sender process is up and running:

[root@node-1 /]# service postgresql-9.4 start
Redirecting to /bin/systemctl start postgresql-9.4.service
[root@node-1 /]# ps auxf |grep postgres
root 28875 0.0 0.1 112640 984 pts/0 S+ 15:14 0:00 _ grep --color=auto postgres
postgres 28864 0.1 1.9 337444 15196 ? S 15:14 0:00 /usr/pgsql-9.4/bin/postgres -D /var/lib/pgsql/9.4/data
postgres 28865 0.0 0.1 190496 1340 ? Ss 15:14 0:00 _ postgres: logger process 
postgres 28867 0.0 0.2 337444 1688 ? Ss 15:14 0:00 _ postgres: checkpointer process 
postgres 28868 0.0 0.2 337444 1696 ? Ss 15:14 0:00 _ postgres: writer process 
postgres 28869 0.0 0.2 337444 1692 ? Ss 15:14 0:00 _ postgres: wal writer process 
postgres 28870 0.0 0.3 337844 2560 ? Ss 15:14 0:00 _ postgres: autovacuum launcher process 
postgres 28871 0.0 0.2 192724 1756 ? Ss 15:14 0:00 _ postgres: stats collector process 
postgres 28873 0.6 0.4 338240 3092 ? Ss 15:14 0:00 _ postgres: wal sender process replication streaming 0/1718C90

11. Check PostgreSQL Synchronous Streaming Database Replication Status

Connect to the master PostgreSQL instance and run the following query to check the replication status:

postgres=# SELECT * FROM pg_stat_replication;
 pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | backend_xmin | state | sent_location | write_location | flush_location | rep
lay_location | sync_priority | sync_state 
 28383 | 16384 | replication | slave_node1 | | | 53789 | 2015-08-10 14:56:13.610889+02 | | streaming | 0/1718D38 | 0/1718D38 | 0/1718D38 | 0/1718D38 | 1 | sync
(1 row)

As you can see the PostgreSQL Synchronous Streaming Database Replication status is OK, the state is “streaming” and the sync_state is “sync” which means the configured replication is synchronous.


Source: https://geekpeek.net/postgresql-synchronous-streaming-database-replication/



Install Oracle Java JDK 6/7/8 on Ubuntu 13.04 / 12.10 / 12.04

Before you install it, remove OpenJDK, if you have it installed:

$ sudo apt-get purge openjdk*

To install Java 8/7/6, do this:

In order not to get issues with the add-apt-repository command, install the following package:

$ sudo apt-get install software-properties-common

Add the PPA:

$ sudo add-apt-repository ppa:webupd8team/java

Update the repo index:

$ sudo apt-get update

Install Java 8:

$ sudo apt-get install oracle-java8-installer

Or, install Java 7:

$ sudo apt-get install oracle-java7-installer

Or, install Java 6:

$ sudo apt-get install oracle-java6-installer

set the java home in /etc/profile

sudo gedit /etc/profile

export JAVA_HOME
export JRE_HOME
export PATH

then execute the javapos.bin file

Create a file in /etc/init.d location named as adempiere like /etc/ini.d/adempiere, copy the given below script into the adempiere file and grant the execution permission by following command “chmod +x /etc/init.d/adempier” Use the following script and replace the ADEMPIERE_HOME and ADEMPIERE_USER with your current requirement. after that use the following command to make adempiere run on startup

“chkconfig adempiere on”  for centos

“update-rc.d adempiere defaults” for ubuntu


# chkconfig: 2345 99 1
# description: Starts and stops the Adempiere ERP system

#Check for valid ADEMPIERE_HOME
if [ -f $ADEMPIERE_HOME/utils/myEnvironment.sh ]; then
. ./myEnvironment.sh Server
echo “Unable to locate myEnvironment.sh, ADEMPIERE_HOME invalid?”

start() {

su – $ADEMPIERE_USER -m -c “cd $ADEMPIERE_HOME/utils; ./RUN_Server2.sh &” >> $CONSOLE_LOG 2>&1

stop() {
su – $ADEMPIERE_USER -m -c “cd $ADEMPIERE_HOME/utils; ./RUN_Server2Stop.sh &” >> $CONSOLE_LOG 2>&1

restart() {

case “$1” in
sleep 30
echo “Usage: $0 {start|stop|restart}”
exit 1

E-Mail notification for Every ssh Login

Posted: November 14, 2015 in Linux

I was tried to configure my ubuntu server to send email notification for every ssh login and i found a blog that is worked for me so i posted this blog to help other to get this easier.

Sometimes you just want something simple. Here’s how you can be notified every time someone logs into a Linux system via ssh (Secure Shell). We’ve assumed that your users run the bash shell, but the same principle can be adopted for other shells.

Put the following in /etc/profile

if [ -n “$SSH_CLIENT” ]; then
TEXT=”$(date): ssh login to ${USER}@$(hostname -f)”
TEXT=”$TEXT from $(echo $SSH_CLIENT|awk ‘{print $1}’)”
echo $TEXT|mail -s “ssh login” you@your.domain

How it works The script /etc/profile is executed at every login (for bash shell users). The if statement will only return true if the user has logged in via ssh, which in turn will cause the indented code block to be run. Next, we then build the text of the message:
$(date) will be replaced by the output of the “date” command
${USER} will be replaced by the user’s login name
$(hostname -f) will be replaced by the full hostname of the system being logged into
The second TEXT line adds to the first, giving the IP address of the system this user is logging in from.

Finally, the generated text is sent in an email to your address.

Linux will, by default, record every system login, whether by ssh or not, in the system log files, but sometimes – particularly for a system that is seldom accessed via ssh – a quick and dirty notification can be useful.
source: https://www.tiger-computing.co.uk/get-linux-to-notify-every-ssh-login/

If you are looking for svn server installation without apache and you need to grant access to particular user to the particular project use this following method it worked for me and right now i am using this in my environment with ubuntu 14.04.

If you plan to expose your Subversion (SVN) repository through your firewall, I would use only HTTPS or SVN+SSH (never straight HTTP or SVN). I prefer SVN+SSH because there is no Apache or SSL setup required, so it is easier to get going (but a little less convenient because you can’t access your repository in a web browser). Second, if you are a home-hoster like me, the SVN protocol serves up over a non-80 port, which is good because some ISP’s (*cough* Verizon) block port 80.

These instructions assume SSH is already active on the server.


Install Subversion

The usual:

sudo apt-get install subversion


Add your local user and the anonymous web user (www-data) to a new group called “subversion”. Change “rbrooks” below accordingly.

sudo groupadd subversion
sudo usermod -a -G subversion rbrooks
sudo usermod -a -G subversion www-data

I like to always verify that it succeeded.

id rbrooks
id www-data

Verify that you see “(subversion)” in the above output.

Create a place for your repositories and permission it. Its location doesn’t necessarily need to be /home/svn.

sudo mkdir /home/svn
cd /home/svn
sudo mkdir myproject
sudo chown -R www-data:subversion myproject
sudo chmod -R g+rws myproject

Create Repository

Create a repository and permission it again in the same way we did above.

sudo svnadmin create /home/svn/myproject
sudo chown -R www-data:subversion /home/svn/myproject
sudo chmod -R g+rws /home/svn/myproject

Some people opt to create a single repository, then make all of their projects subfolders of that. I would recommend you create a separate repository for each project. This way, projects are isolated so they can be permissioned differently if need be. You may decide you need to allow Mikael from Sweden into your project at some point. You may not want him to see all of your other projects (especially some of your questionable side projects). Plus, if you are connecting the repository to a project-management system with an SVN repository browser (eg, Trac), these systems often have a one-to-one relationship between their concept of “Project” and its SVN repository.

Access Control

Edit SVN config file for the new repository:

sudo nano /home/svn/myproject/conf/svnserve.conf

Uncomment (remove the # from) the following line:

password-db = passwd

Ctrl-X to exit and save.

Change the UN(Username) and PW(Password):

sudo nano /home/svn/myproject/conf/passwd

Uncomment one of the example lines under [users], and change to your username and password:

rbrooks = mypassword

Exit and save.

Start SVN Server

Important thing is need to logout or reboot for group permission and modification
take effect

svnserve -d -r /home/svn

Subversion daemon will start in the background and you will be returned to the command prompt. SVN begins listening on default port 3690.


Test from a client machine. We’re going to create a directory in the repository, verify that it exists, then delete it. Change path and username accordingly based on your setup.

Create Directory

svn mkdir -m 'Created Test directory' --username rbrooks svn://hostname/myproject/test

It will ask you for your password. It will be what you placed into the passwd file earlier. If the directory was created successfully, you should see Committed revision 1. Username and password are cached from this point forward. You don’t need to pass the --username param again.


Verify that the folder exists using SVN’s ls command:

svn ls svn://hostname/myproject

SVN should respond with test/.


Test SVN over SSH:

svn ls svn+ssh://hostname/home/svn/myproject

Important: You must use the full path (/home/svn/myproject) to access SVN repository using this access method.

Delete Directory

svn rm -m 'Deleted Test directory' svn+ssh://hostname/home/svn/myproject/test


If you want to expose your repository to the Internet, forward port 3690 to your SVN server. Port forwarding and firewall configuration are beyond the scope of this article.

Filed under Linux

Source : http://www.russbrooks.com/2009/2/1/install-subversion-on-ubuntu-linux

Step 1: Install Apache

First, clean-up yum:

sudo yum clean all

As a matter of best practice we’ll update our packages:

sudo yum -y update

Installing Apache is as simple as running just one command:

sudo yum -y install httpd

Step 2: Allow Apache Through the Firewall

Allow the default HTTP and HTTPS port, ports 80 and 443, through firewalld:

sudo firewall-cmd --permanent --add-port=80/tcp

sudo firewall-cmd --permanent --add-port=443/tcp

And reload the firewall:

sudo firewall-cmd --reload

Step 3: Configure Apache to Start on Boot

And then start Apache:

sudo systemctl start httpd

Be sure that Apache starts at boot:

sudo systemctl enable httpd

To check the status of Apache:

sudo systemctl status httpd

To stop Apache:

sudo systemctl stop httpd

Step Two — Install MySQL (MariaDB)


sudo yum install mariadb-server mariadb
sudo systemctl start mariadb
sudo mysql_secure_installation
sudo systemctl enable mariadb.service






Install the wine

sudo add-apt-repository ppa:ubuntu-wine/ppa
sudo apt-get update
sudo apt-get install wine1.6
sudo apt-get install winetricks

Install the Microsoft Office 2007 package,

after installation microsoft word and excel can be accessible
and power point will not open so do some changes.

open “configurewine” –> libraries –> search ( riched20 ) add –>
edit –> select native window ..

and open power point it will work now.

Subversion Server Setup in Ubuntu

Posted: October 12, 2015 in Linux

This tutorial describes setting up a Subversion server on an Ubuntu system and configuring it for use by a group of developers. The goal is to allow each member of a development team to access the Subversion repositories from a remote location (e.g., a workgroup at office), using the svn protocol.


It is assumed that you already have a basic Ubuntu server running, and that the other developers can connect to it.

Basic Subversion Setup

Begin by installing the Subversion package:

$ sudo apt-get install subversion

Create a folder needed for your repositories. Most people use /home/svn or /usr/local/svn for this purpose, and you can choose either. I personally prefer /usr/local/svn over /home/svn, as I like to keep /home for home directories of real users of the system.

$ sudo mkdir /usr/local/svn

Inside this directory, create another one to hold your repositories:

$ sudo mkdir /usr/local/svn/repos

Now, you need to set some access permissions on those directories. You only want to allow certain users of your system (that is, yourself and the other developers) to access the repositories, so add a new group for those users. Name the group svn.

$ sudo groupadd svn

Then, change the group ownership of /usr/local/svn/repos to the new group using the chgrp command:

$ sudo chgrp svn /usr/local/svn/repos

The members of the svn group also need write access to the repos directory, so use chmod to add the write permission for the group:

$ sudo chmod g+w /usr/local/svn/repos

Additionally, you need to make sure that all new files and directories created in the repos directory (in other words, anything committed to the repositories) will also be owned by the group. To accomplish this, use chmod again to set the set-group-ID bit on the directory, which causes any file created inside it to have the same group ownership as the directory itself. Effectively, everything in repos will belong to the svn group.

$ sudo chmod g+s /usr/local/svn/repos

OK, so you now have the repositories directory with proper permissions, ready to be used by the svn group. Go ahead and add yourself to the group:

$ sudo usermod -a -G svn dev007

However, your new group membership will not be effective for the current session, so you need to log out and log back in. When you’re back, you can verify that your account is recognized as a member of the svn group:

$ groups

dev007 adm dialout cdrom plugdev lpadmin admin sambashare svn

If the other developers have user accounts on your server, add them to the group too:

$ sudo usermod -a -G svn dev008

$ sudo usermod -a -G svn dev009

If they don’t, they will still be able to access the repositories, but only using the basic svn protocol, not the secure svn+ssh method.

Creating a Test Repository

You can now create a repository. In the following steps, I’ll demonstrate how to create a simple test repository containing one text file, and how to check out and commit files. If you’re not familiar with Subversion, then this could be a good exercise to learn the basics. Otherwise, you can skip all the test checkouts and commits and just create the repository for your project.

The repository will be a subdirectory in the repos directory, and will have its group ownership set to svn (thanks to the chmod g+s you did earlier). However, that’s not all – you also need to make sure the repository will be group writable, so that the other members of the svn group will be able to commit files. To do this, set the umask to 002:

$ umask 002

This command sets the new file mode creation mask which controls the default permissions of any new file that you create. The default value is 022 and it corresponds to read/write permissions for the file owner, and read permissions for the group and others. The new value, 002, also gives write permissions to the group, which is just what you need.

Create the repository using the svnadmin command:

$ svnadmin create /usr/local/svn/repos/test

And set back the default umask:

$ umask 022

So you now have an empty repository, waiting for you to commit something to it. But, before you do this, you need to check out the current version (i.e., the empty directory) to create a working copy.

$ svn checkout file:///usr/local/svn/repos/test

Checked out revision 0.

The working copy has been checked out to a new directory named test. Go ahead and create a simple “hello world” text file in that directory:

$ cd test

$ echo ‘Hello, World!’ > hello.txt

Then, add it to version control with the svn add command:

$ svn add hello.txt

A hello.txt

Finally, commit it using svn commit:

$ svn commit -m “Added a ‘hello world’ text file.”

Adding hello.txt Transmitting file data . Committed revision 1.

The hello.txt file is now in the repository.

Accessing the Repository with the Svn Protocol

Remote repository access with the svn protocol requires you to use svnserve, a Subversion server program. Each repository has a svnserve configuration file (stored in the conf subdirectory) which controls how the repository can be accessed with svnserve.

$ gedit /usr/local/svn/repos/test/conf/svnserve.conf

There’s probably some default configuration in the file

Uncomment the following lines

anon-access = none

auth-access = write

password-db = passwd

authz-db = authz

The anon-access = none line denies access to the repository to unauthenticated users (by default, they are allowed read access, so they can do checkouts). The password-db setting tells svnserve where to look for the passwords file when authenticating users,

$ gedit /usr/local/svn/repos/test/conf/authz

Create the group and repository path

Under the [group] enter group name (eg: test_pm) and after “=” enter user name in order to access the repo (eg: arul)

sample entry of my authz file


# harry_and_sally = harry,sally

# harry_sally_and_joe = harry,sally,&joe

test_pm = arul

test_dev = gaj,senthil,padma,avinash,bibin,thiru,dhina,lavanya,suganya

test_rmg = reena,subramanian



# harry = rw

# &joe = rw

#* = rw

@test_pm = rw



#@harry_and_sally = rw

#* = r

@test_pm = rw

@test_dev = rw

@test_rmg = rw


#@harry_and_sally = rw

#* = r

@test_pm = rw



#@harry_and_sally = rw

#* = r

@test_rmg = rw

@test_dev = rw



#@harry_and_sally = rw

#* = r

@test_rmg = rw

@test_dev = rw



#@harry_and_sally = rw

#* = r

@test_pm = rw



#@harry_and_sally = rw

#* = r

@test_pm = rw

@test_rmg = rw

$ gedit /usr/local/svn/repos/test/conf/passwd

This is a password file where you can maintain password’s for all user’s who have access in this repo only.

Sample entry of my passwd file


# harry = harryssecret

# sally = sallyssecret

arul = lEs3D2

senthil = rvWvsn

reena = BxnXZ4

padma = LKO4Qh

OK, the configuration is ready, so you can now launch svnserve.

$ sudo svnserve -d –foreground -r /usr/local/svn/repos

The command-line options tell svnserve to run in daemon mode (-d) as a foreground process (--foreground), and to look for repositories in the repos dir that was created earlier (-r /usr/local/svn/repos). Normally the program should be running in the background (that’s what daemon processes do), but at this moment you only need to test it, so it’s more convenient to run it in the foreground, where you can easily kill it with Ctrl+C.

Now, try accessing the repository using the svn protocol. You can try it on another machine over the network, or on the same computer (in another terminal). In the latter case, make sure you’re not doing the checkout in the same directory where the previous test working copy was checked out, because it won’t work – either delete the test directory, or cd to some other location.

Enter the following svn checkout command, replacing with the IP address of your Subversion server (if you’re testing on the same machine, you can use

$ svn checkout svn:// –username arul

The server will ask you for password:

Authentication realm: <svn://> 08f022d5-400c-4fb4-95d8-b90880c7cc77

Password for ‘arul’:

Then, it proceeds with the checkout.

A test/hello.txt Checked out revision 1.

And there’s your working copy. Now, check if it works the other way – try modifying the file and committing it back to the repository. Open hello.txt with a text editor and add some text:

$ cd test

$ gedit hello.txt

When you’re done, commit it:

$ svn commit -m “Modified the hello.txt file.”

Sending hello.txt Transmitting file data . Committed revision 2.

Sweet, it works both ways.

Svnserve Initialization Script

If you plan on using svnserve in the long run, you probably don’t want to start it from the command-line every time the server is rebooted. The proper way to start system services is with init scripts located in the /etc/init.d directory.

The Subversion package for Ubuntu does not include an init script, so you have to make one yourself. Or, you can download this init script. Save the script as /etc/init.d/svnserve and make it executable:

$ sudo chmod +x /etc/init.d/svnserve

If you chose anything other than /usr/local/svn/repos for the repositories directory, make sure to change the path in the init script.

Run update-rc.d to install the script:

$ sudo update-rc.d svnserve defaults

Adding system startup for /etc/init.d/svnserve … /etc/rc0.d/K20svnserve -> ../init.d/svnserve /etc/rc1.d/K20svnserve -> ../init.d/svnserve /etc/rc6.d/K20svnserve -> ../init.d/svnserve /etc/rc2.d/S20svnserve -> ../init.d/svnserve /etc/rc3.d/S20svnserve -> ../init.d/svnserve /etc/rc4.d/S20svnserve -> ../init.d/svnserve /etc/rc5.d/S20svnserve -> ../init.d/svnserve

And that’s it – svnserve will be started automatically when your system boots up. To start it manually, run this command:

$ sudo /etc/init.d/svnserve start