Monitor Postgres Guide line For postgresql adminstration:

+ To track service of postgres :
    - ps -ef | grep postgres
+ top :
    - top -c -u postgres

+ iostat : Check device status
    - iostat 2 5

+ netstat : information about current network connection
    - netstat -an | grep LISTEN
    - netstat -an | grep LISTEN | grep tcp
    - netstat -an | grep LISTEN | grep PGSQL

+ pg_stat_activilty  : to track number of connections, query activity,...

+ pg_stat_replication : to monitor postgres clustering

+ pg_stat_archvier : to monitor archive files , log files,....

+ pg_stat_bgwriter: checking perform : like check_piont time. ...

+ pg_stat_database : to check status for databases,....

+ pg_stat_all_tables : to check status for tables,....

+ pg_stat_all_indexes : to track indexes,...

+ pg_stat_system_indexes : to check status for indexes,...

+ pg_stat_user_indexes : to track user indexes,....

+ pg_stat_database_conflicts : to check status for conflic like tables,....

**** Useful Queries ****
+ Show all current connections:
    select * from pg_stat_activity;
+ Show all waiting queries:
    select * from pg_stat_activity where waiting='t';
+ Show top 3 longest running queries:
    select datname,usename,now() - query_start as query_runtime from pg_stat_activity order by 3 desc limit 3;

+ du -hcs data/* : Disk space usage

+ Huge Pages
    # grep ^Huge /proc/meminfo

Install Oracle in silent mode 11G Release 2 (11.2) on OEL6

Silent mode installation allows to configure necessary Oracle components without using graphical interface nor any interaction with end user. It’s very useful method especially when you want to prepare standard installation using shell scripts.


Reference Link:  http://dbaora.com/install-oracle-in-silent-mode-11g-release-2-11-2/

Lynis - Security Tool for Audit and Hardening Linux / Unix Systems

System administrator must have known about the importance of security. Maintaining servers are not just make the server is up and running but it should be secure too. Security is not coming by default. We need to tune-up the systems to fit our needs. Since security has a wide coverage, sometimes its easy for us to miss something. Because of that, there is a security tool that can remind system administrators what should they do to secure and harden their systems.


Reference Link :http://linoxide.com/how-tos/lynis-security-tool-audit-hardening-linux/

Securing and Hardening Red Hat Linux Production Systems

Focus of this Article

This Linux Security HOWTO is intended for a technical audience, Linux system administrators, and security people in corporations and organizations that have to use commercial Linux distributions for their production environment. If you are a Linux expert then you may find familiar material here, but you will have difficulties to find documentation on various topics like restricting su access to system and shared accounts only as covered in this article, see Restricting su Access to System and Shared Accounts. 
If you need to make Linux production systems compliant with various audit requirements, then this article should offer a good baseline and starting point. The main objective of this Linux Security guide is to discuss basic Linux security requirements including account policies for production systems that are being audited. This document covers various system services like SSH which are usually enabled and required on all Linux production servers. But it does not cover services or applications like Apache, Samba etc., since these applications/services are usually not needed across all Linux servers and should therefore not be installed on all systems. In fact, these applications warrant their own security HOWTO. Also, this article does not cover security features that require kernel patching. This is not an option for most companies due to vendor support issues.

Reference Link: http://www.puschitz.com/SecuringLinux.shtml

Documenting security best practices - XCCDF introduction

When I have some free time, I try to work on a Gentoo Security Benchmark which not only documents security best practices (loosely based on the Gentoo Security Handbook which hasn't seen much updates in the last few years) but also uses the SCAP protocols. This set of protocols allows security administrators to automate and document many of their tasks, and a security best practices guide is almost a must-have in any organization. So I decided to do a few write-ups about these SCAP protocols and how I hope to be using them more in the future.

In this post, I'm going to focus on a very simple matter: documenting. SCAP goes much, much beyond documenting, but I'll discuss those various features in subsequent posts. The end goal of the series is to have a best practice document for PostgreSQL.

To document the secure state of a component, it is important to first have an idea about what you are going to document. Some people might want to document best practices across many technologies so that there is a coherent, single document explaining the security best practices for the entire organization. In my opinion, that is not manageable in the long term. We tried that with the Gentoo Security Handbook, but you quickly start wrestling with the order of chapters, style concerns and what not. Also, some technologies will be much more discussed in depth than others, making the book look "unfinished".

Personally, I rather focus on a specific technology. For instance: Hardening OpenSSH (very much work in progress - the rules are generated automatically for now and will be rewritten in the near future). It talks about a single component (OpenSSH) allowing the freedom for the author to focus on what matters. By providing security best practices on these component levels, you'll create a set of security best practices that can often be reused. This is what the Center for Internet Security is doing with its benchmarks: popular technologies are described in detail on how to configure them to be more secure.

Once you know what technology you want to describe, we need to consider how this technology is used. Some technologies are very flexible in their setup, and might have different security setups depending on their use. For instance, an OpenLDAP server can be used internally as a public address book, or disclosed on the Internet in a multi-replicated setup with authentication data in it. The security best practices for these deployments will vary. The XCCDF (Extensible Configuration Checklist Description Format)standard allows authors to write a single guide, while taking into account the different deployment approaches through the use ofProfile settings.

In XCCDF, Profiles allow for selectively enabling or disabling document fragments (called Groups) and checks (called Rules - I will post about checks later) or even change values (like the minimum password length) depending on the profile. A document can then describe settings with different profiles depending on the use and deployment of the technology. Profiles can also inherit from each other, so you can have a base (default) security conscious setup, and enhance it through other profiles.

Next to the "how", we also need to consider the structure we want for such a best practice:

• We will have rules in place for the deployment of PostgreSQL itself. These rules range from making sure a stable, patched version is used, to the proper rights on the software files, partitioning and file system rules and operating system level requirements (such as particular kernel parameters).
• We will also have rules for each instance. We could plan on running multiple PostgreSQL instances next to each other, so these rules are distinct from the deployment rules. These rules include settings on instance level, process ownership (in case of running PostgreSQL as different service user), etc.
• We might even have rules for databases and users (roles) in the database.

It might make sense to split the best practices in separate documents, such as one for PostgreSQL infrastructure (which is database-agnostic) and one for PostgreSQL databases (and users). I would start with one document for the technology if I was responsible for the entire definition, but if this responsibility is not with one person (or team), it makes sense to use different documents. Also, as we will see later, XCCDF documents can be "played" against a target. If the target is different (for infrastructure, the target usually is the host on which PostgreSQL is installed, whereas for the database settings the target is probably the PostgreSQL instance itself) I would definitely have the definitions through separate profiles, but that does not mean the document needs to be split either.

Finally, documenting a secure best practice also involves keeping track of the references. It is not only about documenting something and why you think this is the best approach, but also about referring readers to more information and other resources that collaborate your story. These can be generic control objectives (such as those provided by the open security architecture) or specific best practices of the vendor itself or third parties.

At the end, for a PostgreSQL security guide, we would probably start with:

Hardening PostgreSQL
+- Basic setup
+- Instance level configuration
|  +- Pre-startup configuration
|  `- PostgreSQL internal configuration
+- Database recommendations
`- User definitions

Profile-wise, I probably would need an infrastructure profile, an instance profile, a user profile and a database profile. I might even have profiles for the different roles (functional account, administrator and end user profiles which inherit from the user profile) as they will have different rules assigned to them.