<Installation Note Name> IN-Postgresql_from_Source </Installation Note Name> <Title> Installation Notes for Postgresql 9.1.3 in OpenSuse 12.1 </Title> <About> How to install Postgresql from source files </About> <Author> Megat Ahmad Sani </Author> <Location> Kuala Lumpur, Malaysia </Location> <Publisher> uniStreet Press </Publisher> <Version> Number Revision Date Logs 0.1.0 5 May 2012 Base document 0.1.1 1 15 May 2012 Revised installation procedures 0.1.2 2 16 May 2012 Postgresql documentation proposes editing the file

/etc/profile to incorporate environment variables. This causes OS to boot with blank screen. Instead, the procedure has been changed so you could create a blank file <bash.bashrc.local> in /etc. 3 2 June 2012 Added missing instructions for further clarity. </Version> <A> <Begin: For the impatient>

/* Use of <Begin:?> and <End:?> helps to identify relevant sections. Long passages make it difficult to find and/or retrace steps. TULIS semantics make use <Begin:?> and <End:?> in most cases as optional and in some cases as necessary. The ? indicates the subject matter. */

<1.1> <Begin: Using Package Installer> <1.1.1>

/* This is for OpenSuse 12.1 platform. If you are interested for Debian, Fedora, RedHat etc; please search the internet. The author would try to include the instructions for other platforms later if time and resources permit.

Contributors may wish to contribute by inserting in the relevant sections <1.1.2>, <1.1.3> etc. The codes would be available upon request. */

<Begin: OpenSuse {}>

<a> In web browser, type: http://software.opensuse.org/search ; // this is opensuse search site

</a> <b> Type: postgresql </b> ; // this will list all postgresql packages <c> Click the postgresql version </c> ; <d> Choose the opensuse platform version </d> ; // mine is OpenSuse 12.1 <e> Click Direct Install or 1 Click Install </e> ; <f> A *.ymp file will be downloaded </f> ; <g> Click on this file, once it is fully downloaded </g> ; <i> A password window will pop up - enter password </i> ; <j> A second Yast2 window will open. Follow the procedures </j> ; <k> Enable postgresql service by typing the command: yast2 runlevel </k> ; // Scroll to postgresql and click enable if it is listed as "No" <l> Disable postgresql service </l> ; // to test that System V service start/stop script is implemented correctly. <m>

If step <l> above results in error 1, then proceed with section <8> Post Install </m> ;

// You may want to install pgAdmin3 for managing Postgresql. Please download and // install it as necessary.

<End: OpenSuse {}>

<1.1.1> <End: Using Package Installer> </1.1> // If you want to manually install Postgresql - skipping through the notes; then jump straight to // <5> Environment, <6> Prerequisites and <7> Installation Procedures.

<End: For the impatient> </A> <Table of Contents> <1> Summary <2> About TULIS <3> Mission <4> What is Postgresql <5> Environment <6> Prerequisites <7> Installation Procedures <8> Post-Install <9> Troubleshooting <10> References <11> Appendices </Table of Contents>

<1>

<Begin: Summary>

<i> Clear instructions to install Postgresql are difficult to find; especially as there are too numerous resources available on the internet. At times, they are too confusing. </i> <ii> Many of the descriptions do not describe specific environment; from using package installers to manual install. </ii>

<iii> Postgresql documentation manual provides excellent resource for understanding SQL, administration, installation etc. This IN- Postgresql_from_Source has been prepared using those online resources.

</iii>

<iv>

This IN has been prepared using TULIS semantics which are based on TULIS Framework. TULIS semantics employ natural language style as well as liberal use of XML and other programming syntaxes. The ultimate objective is enable user to execute the installation as effortless as possible. </iv>

<v> IN-aaaa stands for installation notes series where (aaaa) is a placeholder for task to be performed. IN-Postgresql_from_Source is part of such series. </v>

<vi> The manner of preparing this IN is to write each set of notes and/or instructions line by line, section by section; then the instructions are carried out to test the validity of each instruction. Despite considerable care that has been exercised, I believe I may have skipped something inadvertently. Should you discover such an instance; please note your comments so that collectively we can make this IN better. </vi>

<vii> TULIS Framework, semantics and all INs are evolving. As such, there must be some weaknesses that would have to be ultimately addressed. Users are highly encouraged to contribute to these developments in any beneficial manner deemed fit. </vii>

<End: Summary>

</1> <2> About TULIS:

// A brief TULIS document is available. Anyone interested may request for a free copy by // writing to megatahmadsani@gmail.com

TULIS is an entity design/analysis framework ("EDAF") with a number of stacks such as Conceptualization (full acronym - ECWC), Essence (EFNAAB), Categorization (CASE), Relations (RbC), Parameters (ConPar) and Processes(PE/S). It also incorporates everyday natural language semantics as well as incorporating syntaxes from XML and other programming languages such as C++, Java etc.

TULIS is envisaged to be used in many applications covering wide disciplines such as system design, social analysis etc.

As you can see, the IN series is a typical application for designing a documentation. // to add more notes if necessary.

</2> <3>

Mission { <i>

To install Postgresql database application manually from source ; /* "source" means that compressed files are pre-configured, i.e not using any of package installer. Package installer makes use of repositories maintained by each respective linux distribution. Sometimes they do not provide the latest application package. Manual installation offers control for your preferences, such as default directory, compilation directives etc. */

</i> }

</3>

// You may skip <4> if you wish. The fact that you have decided to install Postgressql means that you // are already convinced on the benefits of using Postgresql. <4>

<Begin What is Postgresql?>

Postgresql is an object-oriented relational database system. To avoid duplicating resources, please search the internet. Wikipedia is a good source for information on the history of Postgresql and an overview. The latest stable version is 9.1.3. Version 9.2 is beta. What can you do with Postgresql? Plenty! Many applications make use of Postgresql as their database. Most free applications use MySQL as default database. If you plan to develop industrial-strength applications; then Postgresql is the database to adopt.

<End: What is Postgresql?>

</4> <5>

<Begin: Platform Environment>

/* This IN describes installation for the following environment. Whilst the environment is similar to most linux distributions (distros); the author does not guarantee that it will work for you in a different operating environment. */

Environment {

Host: Windows 7 Ultimate 64-bit ; Virtualization Software: Oracle VM VirtualBox 4.1.14r77440 ;

// currently this the latest VirtualBoxGuestAdditions: VBoxGuestAdditions.iso ; // this is required for seamless view, sharing of folders etc. Guest OS: OpenSuse 12.1 64-bit ; Web Server: Apache2.2.x ; PHP: 5.3x ; /*

Should you use virtualization; make sure that you have enough hard disk allocation the first time you create the guest OS under VirtualBox. Though Postgresql itself does not require sizable hard disk space, data will grow and you might want to add more applications as you go along. I had a terrible mess when I tried to extend the virtual disk size. Plan for the applications that you want to incorporate under the guest OS so that you would not want to encounter this situation. Just a friendly reminder! */ }

<End: Platform Environment> </5> <6>

<Begin: Prerequisites>

Prerequisites { <6.1> gmake </6.8> ; // GNU Make. Use command gmake --version to // check. <6.2> gcc </6.2> ; // ISO/ANSI C Compiler. Check with // <tool> --version as above. <6.3> gzip </6.3> ; // GNU zip and tar compression tool <6.4> readline-devel </6.4> ; <6.5> openssl </6.5> ; // optional <6.6> Tcl/Tk </6.6> ; // required if you want to use PgAccess with // postgresql <6.7> JDK </6.7> ; // JDK is Java Development Kit - required to // enable JDBC support <6.8> Ant </6.8> ; // Ant is a Java-based build tool (somewhat like // gmake) that is required for JDBC support.

}

<End: Prerequisites> </6> <7> Installation Procedures { <7.1>

<Begin: Download Postgresql>

<7.1.1>

Go to go: http://www.postgresql.org/download/linux/ ;

/* Make sure you click (underlined) "build from source". Choose the appropriate file. File ends with *.tar.bz2 or *.tar.gz

I prefer to use Multiget (a Linux download manager) as it provides "multiple tries" should there be any disconnection from the internet. Chrome and Firefox does not provide "resume" ability after disconnection. Search for multiget repository and install. It is worth the effort.

If you have Kget by default; uninstall it by typing in terminal window: zypper rm kget.

I have had various problems with Kget! It starts the first time. The next time you launch it, Kget cannot be traced anywhere! A bug? I don't know. I have searched for answers; and I am yet to understand this bizarre behaviour! */

</7.1.1>

<7.1.2>

Download to: /etc/home/<your_user_name>/Downloads ;

/* Use your user name that you assign when you install OpenSuse 12.1. You may wish to download to any folder. However, it is a good practice to download to your Downloads folder as it is easier to remember. */

</7.1.2>

<End: Download Postgresql>

</7.1> <7.2>

<Begin: Create user "postgres"> // need user 'postgres' for creating databases. 'root' should be avoided for security reasons.

<7.2.1>

In terminal, type: su - -c "useradd postgres" ; // if you are a root user; then just type "useradd postgres" without the quotes.

</7.2.1>

<End: Create user "postgres">

</7.2> <7.3>

<Begin: Extract compressed files>

<7.3.1>

In terminal, type: tar jxf postgresql-9.1.3.tar.bz2 ;

/* for file ending with .tar.bz2 or for .tar.gz use: tar -zxvf postgresql-9.1.3.tar.gz */

</7.3.1>

<7.3.2>

In terminal, type: cd postgresql-9.1.3 ; // assuming you are in same directory as in ~/Downloads

</7.3.2>

<7.3.3>

In terminal|type: ls ; // to list directories and files. 'configure' file should be available

</7.3.3>

<Take a break or continue reading this section>

You should take a break as you need to study configuration options before you decide to configure.

/* If you want to compile with default configuration, just proceed with the next steps as in <7.4> */

<Begin: Configuration notes> // you may skip this.

As there are many configuration options, please visit: http://www.postgresql.org/docs/9.1/static/install-procedure.html

// BTW: I prefer to compile using --prefix=/opt/pgsql.

// This will install Postgresql in /opt/pgsql

<End: Configuration notes>

</Break>

<End: Extract compressed files> </7.3> <7.4>

<Begin: Install readline-devel utility>

<7.4.1>

In terminal, type: yast2 -i readline-devel ; // when GUI appears click [skip autorefresh]

</7.4.1>

<7.4.2>

In GUI, click: accept ; // This will retrieve package and install.

</7.4.2>

<End: Install readline-devel utility>

</7.4>

<7.5>

<Begin: Configure>

<7.5.1>

In terminal, type: cd /home/<your_user_name>/Downloads/postgresql-9.1.3 ; // Skip this, if you are already in this directory

</7.5.1>

<7.5.2>

In terminal, type: ./configure --prefix=/opt/pgsql ;

/* This will install Postgresql in /opt/pgsql ; and data in /var/lib/pgsql/data. The actual files will be installed into various subdirectories; no files will ever be installed directly into the PREFIX directory.

It does not really matter where you put your Postgresql. Default configuration will put Postgresql in /usr/local/pgsql

Note if there are errors. In my case configure cannot find readline utility and zlib. That was the reason I included the instruction <7.4> above. For ease, use yast2 -i to search for missing libraries. */

</7.5.2>

<End: Configure>

</7.5> <7.6>

<Begin: gmake>

// compiling postgresql

<7.6.1>

Iin terminal, type: gmake world ; /* "gmake world" is to include postgresql documentation. If errors; go back to <7.4> as for my case. If everything is OK, you should get a message "All of PostgreSQL successfully made. Ready to install" */

</7.6.1>

<End: gmake>

</7.6>

<7.7>

<Begin: Regression test> // Recommended

<7.7.1> Launch Dolphin (super user mode) </7.7.1> ;

<7.7.2>

Navigate to: /home/<your_user_name>/Downloads/postgresql-9.1.3/src/test </7.7.2>

<7.7.3> Change Permission: Can View and Modify Content </7.7.3> ;

// for group and others. Alternatively, you can use command line

<7.7.4> In terminal, type: su - postgres </7.7.4> ;

// change to postgres user. Cannot initialize db as root.

<7.7.5> In terminal, type: gmake check </7.7.5> ;

/* Iinitialize db and test. If everything is OK; you should get a message something like this "All 126 tests passed." */

<End: Regression test>

</7.7>

<7.8>

<Begin: gmake install-world > // install postgresql

<7.8.1> In terminal, type: su </7.8.1> ; // go back as root

<7.8.2> Type: <password> </7.8.2> ; // your password

<7.8.3> Type: gmake install-world </7.8.3> ;

/* If you compiled with "gmake install"; then just enter this command instead of the above. if everything is OK; you should get a message "PostgreSQL installation complete" */

<End: gmake install-world>

</7.8>

<7.9>

<Begin: Install compiled programs and libraries>

<7.9.1> In terminal, type: su -c "gmake install-world" </7.9.1> ;

<7.9.2> In terminal, type: <password> </7.9.2> ;

// programs & libraries will be installed

<End: Install compiled program and libraries>

</7.9> <7.10>

<Begin: Change ownership of postgresql>

<7.10.1> In terminal, type: su -c "chown -R postgres /var/lib/pgsql" </7.10.1>; // Locate where pgsql data resides using Find Files and Folders. This command // changes owner to postgres for data folder. <End: Change ownership of postgresql>

</7.10>

<7.11>

/* This step is only necessary for version below Postgresql 9.1. Skip this for Postgresql 9.1 as headers all already included in default */

<Begin: install all headers>

<7.11.1> In terminal, type: su -c "gmake install-all-headers" </7.11.1> ;

<7.11.2> In terminal, type: <password> ; <End: install all headers>

</7.11>

<7.12>

<Begin: Set-up environment variables>

<7.12.1> Launch Dolphin(super user) </7.12.1> ;

<7.12.2> Navigate to: /etc </7.12.2> ;

<7.12.2a> In View menu, click Show Hidden Files </7.12.2a> ;

<7.12.3> Create a new file as: bash.bashrc.local </7.12.3> ;

<7.12.4> Open <bash.bashrc.local> with KWrite </7.12.4> ;

<7.12.5>

Insert the following: // Please note that if you had compiled with --prefix=what_ever_path; // then substitute with <your_what_ever_path>

PATH=$PATH:/opt/pgsql/bin MANPATH=$MANPATH:/opt/pgsql/man LD_LIBRARY_PATH=/opt/pgsql/lib64 export LD_LIBRARY_PATH

</7.12.5>

<7.12.6> Save the file </7.12.6> ;

<End: Set-up environment variables>

</7.12>

<7.13>

<Begin: Initialize database>

<7.13.1> Launch Dolphin (super user) </7.13.1> ;

<7.13.2>

Navigate to: /opt/pgsql ; Create folder named <data> ; Right-click <Properties> ; Select Permission tab ; Change permission for group and others: can view and modify content ; Change user to: postgres ; Change group to: root ; Click OK ;

</7.13.2>

<7.13.3>

In terminal, type: su postgres ; type: /opt/pgsql/bin/initdb -D /opt/pgsql/data ;

</7.13.3>

<End: Initialize database>

<7.14>

<Begin: Run postmaster in the background>

<7.14.1>

In terminal, type: /opt/pgsql/bin/pg_ctl start -D /var/lib/pgsql/data -l /var/lib/pgsql/data/logfile.txt ;

// Should it return some errors; it may be necessary that you reboot or // logout, so that the environment variables have been registered properly.

</7.14.1>

<End: Run postmaster in the background>

</7.14>

<7.15>

<Begin: How to install postgresql as a runlevel service>

/* Since we did not use yast2 to install postgresql; it would not appear as a runlevel service. Therefore we need to install so that it runs at boot time. Please read up on runlevel service note below for further understanding. */

<Notes>

<1> Excerpts taken from:

http://www.commandprompt.com/ppbook/x486

The PostgreSQL SysV Script The SysV script will allow the graceful control of the PostgreSQL database through the use of the SysV runlevel system. The SysV script can be used for starting, stopping, and status-checking of PostgreSQL. It is known to work with most Red Hat based versions of Linux, including Mandrake; however, it should work with other SysV systems (e.g., UnixWare, Solaris, etc.) with little modification. The script is named linux. To use it, you will first need to copy the linux script to your init.d directory. You may require root access to do this. First, change to the directory where you unpacked the PostgreSQL source. In our case, the path to that directory is:

/usr/local/src/postgresql-7.1.3/.

Then, issue a cp command to copy the script from contrib/start-scripts into

the init.d directory. Example 2-19 demonstrates how to do this on a Red Hat Linux system.

Example 2-19. Copying the linux script

$ cd /usr/local/src/postgresql-7.1.3/ su -c "cp contrib/start-scripts/linux /etc/rc.d/init.d/postgresql"

Example 2-19 arbitrarily re-names the new copy to postgresql; you may call it whatever you prefer, though it is typically named either postgresql, or postgres. You will need to make the script file executable after copying it. To do so, use the command shown in Example 2-20.

Example 2-20. Making the linux script executable

su -c "chmod a+x /etc/rc.d/init.d/postgresql" </1>

<2> Excerpts taken from:

http://www.linuxforums.org/forum/suse-linux/81386-postgresql-yast-system-services.html

When you have finished the postgresql installation, navigate to the contrib/start-scripts subdirectory in the postgresql source directory. Copy the linux/unix startup script thats in there and put it in /etc/init.d. Make it executable and name it something like postgresql. Edit the file so that the postgresql user is the same in the script as the one you setup for your system. After that do something like:

Code: #chkconfig --add postgresql #chkconfig postgresql on

The above will setup postgresql to start whenever you start or reboot the system. To start it immediately without a reboot, do:

Code: #/etc/init.d/postgresql start

</2>

</Notes>

<7.15.1>

Launch Dolphin(SU) ; Navigate to:

/home/<your_user_name>/Downloads/postgresql-9.1.3/contrib/start-scripts ;

Copy: "linux" to /etc/init.d/ ; // file named "linux" Rename: "linux" to "postgresql" ;

/* It could be any name, but it is better to use something that is easy to remember. */

Edit: prefix=/opt/pgsql ; PGDATA="/opt/pgsql/data" ; PGUSER=postgres ; PATH=/opt/pgsql/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin /* Ensure that the path to the directories are correct as per your postgresql installation earlier. */

Save file ; Make it executable -> Properties|Permission: click executable and OK ; In terminal, type: yast2 runlevel ;

// If there is any error; then launch Yast2 from Start menu

// and choose System|System Services. Select Advanced ; At the bottom, click 3 and 5 ; Save ; Before you exit, save the configuration ; Reboot by typing in terminal: reboot ;

</7.15.1>

<7.15.2>

// This is only necessary if the above fails.

In terminal, make symbolic link:

ln -s /etc/init.d/postgresql /etc/rc.d/rc0.d/K02postgresql ; //repeat as below

ls -s /etc/init.d/postgresql /etc/rc.d/rc1.d/K02postgresql ; ls -s /etc/init.d/postgresql /etc/rc.d/rc2.d/K02postgresql ; ls -s /etc/init.d/postgresql /etc/rc.d/rc3.d/S98postgresql ; ls -s /etc/init.d/postgresql /etc/rc.d/rc4.d/S98postgresql ;

ls -s /etc/init.d/postgresql /etc/rc.d/rc5.d/S98postgresql ;

Reboot, type: reboot ; // to allow changes to take effect

In terminal as root, type: yast2 runlevel ;

// If this command failed; then open yast (GUI) and click // System|System Services(Runlevel).

Scroll to: postgresql ; // posgtresql service should have been enabled.

</7.15.2>

<End: How to install postgresql as a runlevel service>

</7.15> </7> <8>

<Post Install> <Begin: Install pgAdmin3 for database management console>

<Notes on Options>

You have three (2) options:

Option 1: Install from package using yast2 GUI Option 2: Install from source

Either way, it is going to be some hassles. If you use option 2 then the normal procedures apply: configure-->make-->make install This would be a good way to learn as it will allow you to become familiar with linux-based installation process. Investment in some readings would definitely be required. For this Installation Note, we are going to use Option 1 as this is the simplest.

</Notes on Options>

// This is option 1: <8.1>

In terminal as root, type: yast2 -i ; // using GUI. Click skip autorefresh to save time In filter field, enter: pggadmin3 ; Select: pgadmin3 ; /* !!!Do not select postgresql!!!

Choosing so will undo your manual installation of postgresql. All your effort will be wasted. */ Click: accept ; Click: accept suggestion to install additional package ; Wait till it finishes installation ; // Yast2 installer will close once it is OK

</8.1>

<8.2> <8.2.1>

<Begin: Edit pg_hba.conf and postgresq.conf file>

<8.2.1.1> // This is for pg_hba.conf

Launch Dolphin (SU) ; Navigate to /opt/pgsql/data ; Scroll to file pg_hba.conf ; Open file with KWrite ; Ensure that the entry appear somewhat like below:

# TYPE DATABASE USER ADDRESS METHOD # "local" is for Unix domain socket connections only local all all trust # IPv4 local connections: host all all 127.0.0.1/32 trust # IPv6 local connections: host all all ::1/128 trust # Allow replication connections from localhost, by a user with the # replication privilege. #local replication postgres trust #host replication postgres 127.0.0.1/32 trust #host replication postgres ::1/128 trust

/* If everything is OK, save file and exit. */

</8.2.1.1> <8.2.1.2> // This is for postgresql.conf

With Dolphin (SU) already launched, open postgresql.conf with KWrite ; Ensure that:

data_directory = '/opt/pgsql/data' ; hba_file = '/opt/pgsql/data' ; listen_addresses = 'localhost' ; port = 5432

/*

Use your installed directory. */

</8.2.1.2> <End: Edit pg_hba.conf and postgresql.conf file> </8.2.1> <8.2.2> <Begin: Test pgAdmin3 and Postgresql>

Click: start menu ; // Opensuse gecko icon In filter, pgAdmin3 ; // it will autocomplete Launch pgAdmin3 ; Click on Server icon and right-click "Connect" ; In the pop-up window, enter:

Name: postgresql // any name will do Host: localhost User: postgres Group: postgres Password: <your_postgres_password> Disable save password Click OK

/* If it cannot connect; check that pg_hba.conf, postgresql.conf have been configured correctly.

Make sure that you uncomment localhost server and port 5432 in postgresql.conf file.

In pg_hba.conf; change authorization to "trust" for all, IPv4 and IPv6

Also make sure that postgresql service is running. Please restart the server.

Your database is ready! You are done. Consider this an important milestone in your computing journey */

<End: Test pgAdmin3 and Postgresql> </8.2.2>

</8.2>

<End: Install pgAdmin3 for database management console>

</8>

<9>

<Begin: Troubleshooting Postgresql installation>

<9.i>

OpenSuse loads with blank screen. Nothing seems to be working. Solution: <9.i.1> Shutdown OS. If necessary force a shutdown </9.i.1> ; <9.i.2> Start OS and choose Failsafe loading </9.i.2> ; <9.i.3>

When the command prompt appears, type in username and password </9.i.3> <9.i.4>

// The next operation requires you to become 'root' user Type: su ; Type: <password> ; After OS loads, launch Dolphin (super user) ; Navigate to /etc ; Locate a file name 'bash.profile.local' or '.bash.profile.local' ; Delete it ; // !!!Make sure that '.profile' or 'profile' is not // deleted!!!

Reboot OS ; // It should boot normally now

<9.i.4/> <9.i.5> Create a new 'bash.profile.local' in /etc/init.d folder </9.i.5> ; // Follow instruction as in <7>

</9.i>

<9.1>

Cannot install Postgresql Solution: <9.1.1> The easiest is to install through Yast2 software management </9.1.1> ;

// It will take care of the dependencies. Search for platform-specific // repositories for Postgresql

<9.1.2>

If you downloaded the source files, make sure that required dependent packages are installed // ./configure will list required dependencies as per your preferred options // or default should it encounter missing packages.

</9.1.2>

</9.1>

<9.2>

Cannot initialize database

Solution:

<9.2.1>

Check that 'data' folder has been created with permission for 'postgres' as owner and group

</9.2.1> <9.2.2> Check that 'data' folder is empty of contents </9.2.2> ; <9.2.3> Check that -D with correct path to 'data' folder is entered </9.2.3> ;

</9.2>

<9.3>

Cannot connect to server

Solution:

<9.3.1> Check that pg_hba.conf is configured properly </9.3.1> ; <9.3.2> Check that postgresql.conf is configured properly </9.3.2> ; <9.3.3> Check that postgresql server is running </9.3.3> ;

</9.3>

<9.4>

Postgresql is not available in yast2 runlevel service

Solution:

<9.4.1>

If you installed postgresql manually, you have to copy 'linux' file to /etc/init.d and rename it to 'postgresql' // Make sure that the correct folders are being pointed out (used in the // path).

</9.4.1>

</9.4>

<9.5>

Cannot enable/disable runlevel service Solution:

<9.5.1>

Make sure the directory path in file /etc/init.d/bash.bashrc.local is correct

</9.5.1>

</9.5>

<End: Troubleshooting Postgresql installation> </9>

<10> <Begin: References>

<10.1> Postgresql download location: http://www.postgresql.org/download/

</10.1> <10.2>

Postgresql 9.1 Documentation: http://www.postgresql.org/docs/9.1/interactive/index.html

</10.2> <10.3>

OpenSuse 12.1 Postgresql Repositories: http://download.opensuse.org/repositories/server:/database:/postgresql/openSUSE_12.1/

// You need to add this repo to Yast Software Management Repositories if // you want to install through Yast.

</10/3> <10.4> pgAdmin3 website: http://www.pgadmin.org/ </10.4> <10.5> History of Postgresql: http://www.postgresql.org/about/history/ </10.5> <10.6>

Postgresql contributed modules (contrib): http://www.postgresql.org/docs/9.1/interactive/contrib.html/

</10.6> <End: References> </10>

<11> <Begin: Appendices> <11.1>

<Begin: Excerpts from Postgresql Documentation>

15.4. Installation Procedure

1. Configuration

The first step of the installation procedure is to configure the source tree for your system and choose the options you would like. This is done by running the configure script. For a default installation, simply enter:

./configure

This script will run a number of tests to determine values for various system dependent variables and detect any quirks of your operating system, and finally will create several files in the build tree to record what it found. You can also run configure in a directory outside the source tree, if you want to keep the build directory separate. This procedure is also called a VPATH build. Here's how:

mkdir build_dir cd build_dir /path/to/source/tree/configure [options go here] gmake

The default configuration will build the server and utilities, as well as all client applications and interfaces that require only a C compiler. All files will be installed under/usr/local/pgsql by default.

You can customize the build and installation process by supplying one or more of the following command line options to configure:

--prefix=PREFIX

Install all files under the directory PREFIX instead of /usr/local/pgsql. The actual files will be installed into various subdirectories; no files will ever be installed directly into the PREFIX directory. (Comment by author: on my installation the files were installed under prefix - /opt/pgsql)

If you have special needs, you can also customize the individual subdirectories with the following options. However, if you leave these with their defaults, the installation will be relocatable, meaning you can move the directory after installation. (The man and doc locations are not affected by this.)

For relocatable installs, you might want to use configure's --disable-rpath option. Also, you will need to tell the operating system how to find the shared libraries.

--exec-prefix=EXEC-PREFIX

You can install architecture-dependent files under a different prefix, EXEC-PREFIX, than what PREFIX was set to. This can be useful to share architecture-independent files between hosts. If you omit this, then EXEC-PREFIX is set equal to PREFIX and both architecture-dependent and independent files will be installed under the same tree, which is probably what you want.

--bindir=DIRECTORY

Specifies the directory for executable programs. The default is EXEC-PREFIX/bin, which normally means /usr/local/pgsql/bin.

--sysconfdir=DIRECTORY

Sets the directory for various configuration files, PREFIX/etc by default.

--libdir=DIRECTORY

Sets the location to install libraries and dynamically loadable modules. The default is EXEC-PREFIX/lib.

--includedir=DIRECTORY

Sets the directory for installing C and C++ header files. The default is PREFIX/include.

--datarootdir=DIRECTORY

Sets the root directory for various types of read-only data files. This only sets the default for some of the following options. The default is PREFIX/share.

--datadir=DIRECTORY

Sets the directory for read-only data files used by the installed programs. The default is DATAROOTDIR. Note that this has nothing to do with where your database files will be placed.

--localedir=DIRECTORY

Sets the directory for installing locale data, in particular message translation catalog files. The default is DATAROOTDIR/locale.

--mandir=DIRECTORY

The man pages that come with PostgreSQL will be installed under this directory, in their respective manx subdirectories. The default is DATAROOTDIR/man.

--docdir=DIRECTORY

Sets the root directory for installing documentation files, except "man" pages. This only sets the default for the following options. The default value for this option is DATAROOTDIR/doc/postgresql.

--htmldir=DIRECTORY

The HTML-formatted documentation for PostgreSQL will be installed under this directory. The default is DATAROOTDIR.

Note: Care has been taken to make it possible to install PostgreSQL into shared installation locations (such as /usr/local/include) without interfering with the namespace of the rest of the system. First, the string "/postgresql" is automatically appended to datadir, sysconfdir, and docdir, unless the fully expanded directory name already contains the string "postgres" or "pgsql". For example, if you choose /usr/localas prefix, the documentation will be installed in /usr/local/doc/postgresql, but if the prefix is /opt/postgres, then it will be in /opt/postgres/doc. The public C header files of the client interfaces are installed into includedir and are namespace-clean. The internal header files and the server header files are installed into private directories underincludedir. See the documentation of each interface for information about how to access its header files. Finally, a private subdirectory will also be created, if appropriate, underlibdir for dynamically loadable modules.

--with-includes=DIRECTORIES

DIRECTORIES is a colon-separated list of directories that will be added to the list the compiler searches for header files. If you have optional packages (such as GNU Readline) installed in a non-standard location, you have to use this option and probably also the corresponding --with-libraries option.

Example: --with-includes=/opt/gnu/include:/usr/sup/include.

--with-libraries=DIRECTORIES

DIRECTORIES is a colon-separated list of directories to search for libraries. You will probably have to use this option (and the corresponding --with-includes option) if you have packages installed in non-standard locations.

Example: --with-libraries=/opt/gnu/lib:/usr/sup/lib.

--enable-nls[=LANGUAGES]

Enables Native Language Support (NLS), that is, the ability to display a program's messages in a language other than English. LANGUAGES is an optional space-separated list of codes of the languages that you want supported, for example --enable-nls='de fr'. (The intersection between your list and the set of actually provided translations will be computed automatically.) If you do not specify a list, then all available translations are installed.

To use this option, you will need an implementation of the Gettext API; see above.

--with-pgport=NUMBER

Set NUMBER as the default port number for server and clients. The default is 5432. The port can always be changed later on, but if you specify it here then both server and clients will have the same default compiled in, which can be very convenient. Usually the only good reason to select a non-default value is if you intend to run multiple PostgreSQL servers on the same machine.

--with-perl

Build the PL/Perl server-side language.

--with-python

Build the PL/Python server-side language.

--with-tcl

Build the PL/Tcl server-side language.

--with-tclconfig=DIRECTORY

Tcl installs the file tclConfig.sh, which contains configuration information needed to build modules interfacing to Tcl. This file is normally found automatically at a well-known location, but if you want to use a different version of Tcl you can specify the directory in which to look for it.

--with-gssapi

Build with support for GSSAPI authentication. On many systems, the GSSAPI (usually a part of the Kerberos installation) system is not installed in a location that is searched by default (e.g., /usr/include, /usr/lib), so you must use the options

--with-includes and --with-libraries in addition to this option.

Configure will check for the required header files and libraries to make sure that your GSSAPI installation is sufficient before proceeding.

--with-krb5

Build with support for Kerberos 5 authentication. On many systems, the Kerberos system is not installed in a location that is searched by default (e.g., /usr/include, /usr/lib), so you must use the options --with-includes and --with-libraries in addition to this option. configure will check for the required header files and libraries to make sure that your Kerberos installation is sufficient before proceeding.

--with-krb-srvnam=NAME

The default name of the Kerberos service principal (also used by GSSAPI). postgres is the default. There's usually no reason to change this unless you have a Windows environment, in which case it must be set to upper case POSTGRES.

--with-openssl

Build with support for SSL (encrypted) connections. This requires the OpenSSL package to be installed. configure will check for the required header files and libraries to make sure that your OpenSSL installation is sufficient before proceeding.

--with-pam

Build with PAM (Pluggable Authentication Modules) support.

--with-ldap

Build with LDAP support for authentication and connection parameter lookup (see Section 31.16 and Section 19.3.8 for more information). On Unix, this requires the OpenLDAPpackage to be installed. On Windows, the default WinLDAP library is used. configure will check for the required header files and libraries to make sure that your OpenLDAPinstallation is sufficient before proceeding.

--without-readline

Prevents use of the Readline library (and libedit as well). This option disables command-line editing and history in psql, so it is not recommended.

--with-libedit-preferred

Favors the use of the BSD-licensed libedit library rather than GPL-licensed Readline. This option is significant only if you have both libraries installed; the default in that case is to use Readline.

--with-bonjour

Build with Bonjour support. This requires Bonjour support in your operating system. Recommended on Mac OS X.

--with-ossp-uuid

Build components using the OSSP UUID library. Specifically, build the uuid-ossp module, which provides functions to generate UUIDs.

--with-libxml Build with libxml (enables SQL/XML support). Libxml version 2.6.23 or later is required for this feature. Libxml installs a program xml2-config that can be used to detect the required compiler and linker options. PostgreSQL will use it automatically if found. To specify a libxml installation at an unusual location, you can either set the environment variable XML2_CONFIG to point to the xml2-config program belonging to the installation, or use the options --with-includes and

--with-libraries. --with-libxslt

Use libxslt when building the xml2 module. xml2 relies on this library to perform XSL transformations of XML.

--disable-integer-datetimes Disable support for 64-bit integer storage for timestamps and intervals, and store datetime values as floating-point numbers instead. Floating-point datetime storage was the default in PostgreSQL releases prior to 8.4, but it is now deprecated, because it does not support microsecond precision for the full range of timestamp values. However, integer-based datetime storage requires a 64-bit integer type. Therefore, this option can be used when no such type is available, or for compatibility with applications written for prior versions of PostgreSQL. See Section 8.5 for more information.

--disable-float4-byval Disable passing float4 values "by value", causing them to be passed "by reference" instead. This option costs performance, but may be needed for compatibility with old user-defined functions that are written in C and use the "version 0" calling convention. A better long-term solution is to update any such functions to use the "version 1" calling convention.

--disable-float8-byval Disable passing float8 values "by value", causing them to be passed "by reference" instead. This option costs performance, but may be needed for compatibility with old user-defined functions that are written in C and use the "version 0" calling convention. A better long-term solution is to update any such functions to use the "version 1" calling convention. Note that this option affects not only float8, but also int8 and some related types such as timestamp. On 32-bit platforms, --disable-float8-byval is the default and it is not allowed to select --enable-float8-byval.

--with-segsize=SEGSIZE Set the segment size, in gigabytes. Large tables are divided into multiple operating-system files, each of size equal to the segment size. This avoids problems with file size limits that exist on many platforms. The default segment size, 1 gigabyte, is safe on all supported platforms. If your operating system has "largefile" support (which most do, nowadays), you can use a larger segment size. This can be helpful to reduce the number of file descriptors consumed when working with very large tables. But be not to select a value larger than is supported by your platform and the file systems you intend to use. Other tools you wish to use, such as tar, could also set limits on the usable file size. It is recommended, though not absolutely required, that this value be a power of 2. Note that changing this value requires an initdb.

--with-blocksize=BLOCKSIZE

Set the block size, in kilobytes. This is the unit of storage and I/O within tables. The default, 8 kilobytes, is suitable for most situations; but other values may be useful in special cases. The value must be a power of 2 between 1 and 32 (kilobytes). Note that changing this value requires an initdb.

--with-wal-segsize=SEGSIZE Set the WAL segment size, in megabytes. This is the size of each individual file in the WAL log. It may be useful to adjust this size to control the granularity of WAL log shipping. The default size is 16 megabytes. The value must be a power of 2 between 1 and 64 (megabytes). Note that changing this value requires an initdb.

--with-wal-blocksize=BLOCKSIZE Set the WAL block size, in kilobytes. This is the unit of storage and I/O within the WAL log. The default, 8 kilobytes, is suitable for most situations; but other values may be useful in special cases. The value must be a power of 2 between 1 and 64 (kilobytes). Note that changing this value requires an initdb.

--disable-spinlocks Allow the build to succeed even if PostgreSQL has no CPU spinlock support for the platform. The lack of spinlock support will result in poor performance; therefore, this option should only be used if the build aborts and informs you that the platform lacks spinlock support. If this option is required to build PostgreSQL on your platform, please report the problem to the PostgreSQL developers.

--disable-thread-safety Disable the thread-safety of client libraries. This prevents concurrent threads in libpq and ECPG programs from safely controlling their private connection handles.

--with-system-tzdata=DIRECTORY PostgreSQL includes its own time zone database, which it requires for date and time operations. This time zone database is in fact compatible with the "zoneinfo" time zone database provided by many operating systems such as FreeBSD, Linux, and Solaris, so it would be redundant to install it again. When this option is used, the system-supplied time zone database in DIRECTORY is used instead of the one included in the PostgreSQL source distribution. DIRECTORY must be specified as an absolute path./usr/share/zoneinfo is a likely directory on some operating systems. Note that the installation routine will not detect mismatching or erroneous time zone data. If you use this option, you are advised to run the regression tests to verify that the time zone data you have pointed to works correctly with PostgreSQL. This option is mainly aimed at binary package distributors who know their target operating system well. The main advantage of using this option is that the PostgreSQL package won't need to be upgraded whenever any of the many local daylight-saving time rules change. Another advantage is that PostgreSQL can be cross-compiled more straightforwardly if the time zone database files do not need to be built during the installation.

--without-zlib

Prevents use of the Zlib library. This disables support for compressed archives in pg_dump and pg_restore. This option is only intended for those rare systems where this library is not available.

--enable-debug Compiles all programs and libraries with debugging symbols. This means that you can run the programs in a debugger to analyze problems. This enlarges the size of the installed executables considerably, and on non-GCC compilers it usually also disables compiler optimization, causing slowdowns. However, having the symbols available is extremely helpful for dealing with any problems that might arise. Currently, this option is recommended for production installations only if you use GCC. But you should always have it on if you are doing development work or running a beta version.

--enable-coverage If using GCC, all programs and libraries are compiled with code coverage testing instrumentation. When run, they generate files in the build directory with code coverage metrics. See Section 30.4 for more information. This option is for use only with GCC and when doing development work.

--enable-profiling If using GCC, all programs and libraries are compiled so they can be profiled. On backend exit, a subdirectory will be created that contains the gmon.out file for use in profiling. This option is for use only with GCC and when doing development work.

--enable-cassert

Enables assertion checks in the server, which test for many "cannot happen" conditions. This is invaluable for code development purposes, but the tests can slow down the server significantly. Also, having the tests turned on won't necessarily enhance the stability of your server! The assertion checks are not categorized for severity, and so what might be a relatively harmless bug will still lead to server restarts if it triggers an assertion failure. This option is not recommended for production use, but you should have it on for development work or when running a beta version.

--enable-depend Enables automatic dependency tracking. With this option, the makefiles are set up so that all affected object files will be rebuilt when any header file is changed. This is useful if you are doing development work, but is just wasted overhead if you intend only to compile once and install. At present, this option only works with GCC.

--enable-dtrace Compiles PostgreSQL with support for the dynamic tracing tool DTrace. See Section 27.4 for more information. To point to the dtrace program, the environment variable DTRACE can be set. This will often be necessary because dtrace is Extra command-line options for the dtrace program can be specified in the environment variable DTRACEFLAGS. On Solaris, to include DTrace support in a 64-bit binary, you must specify DTRACEFLAGS="-64" to configure. For example, using the GCC compiler:

./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ... Using Sun's compiler:

./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ...

If you prefer a C compiler different from the one configure picks, you can set the environment variable CC to the program of your choice. By default, configure will pick gcc if available, else the platform's default (usually cc). Similarly, you can override the default compiler flags if needed with the CFLAGS variable. You can specify environment variables on the configure command line, for example:

./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe' Here is a list of the significant variables that can be set in this manner:

BISON Bison program

CC C compiler

CFLAGS Options to pass to the C compiler

CPP C preprocessor

CPPFLAGS Options to pass to the C preprocessor

DTRACE

Location of the dtrace program

DTRACEFLAGS Options to pass to the dtrace program

FLEX Flex program

LDFLAGS Options to use when linking either executables or shared libraries

LDFLAGS_EX Additional options for linking executables only

LDFLAGS_SL Additional options for linking shared libraries only

MSGFMT msgfmt program for native language support

PERL Full path to the Perl interpreter. This will be used to determine the dependencies for building PL/Perl.

PYTHON Full path to the Python interpreter. This will be used to determine the dependencies for building PL/Python. Also, whether Python 2 or 3 is specified here (or otherwise implicitly chosen) determines which variant of the PL/Python language becomes available. See Section 42.1 for more information.

TCLSH Full path to the Tcl interpreter. This will be used to determine the dependencies for building PL/Tcl, and it will be substituted into Tcl scripts.

XML2_CONFIG xml2-config program used to locate the libxml installation. 2. Build To start the build, type:

gmake (Remember to use GNU make.) The build will take a few minutes depending on your hardware. The last line displayed should be:

All of PostgreSQL is successfully made. Ready to install. If you want to build everything that can be built, including the documentation (HTML and man pages), and the additional modules (contrib), type instead:

gmake world The last line displayed should be:

PostgreSQL, contrib and HTML documentation successfully made. Ready to install.

3. Regression Tests If you want to test the newly built server before you install it, you can run the regression tests at this point. The regression tests are a test suite to verify that PostgreSQL runs on your machine in the way the developers expected it to. Type:

gmake check (This won't work as root; do it as an unprivileged user.) Chapter 30 contains detailed information about interpreting the test results. You can repeat this test at any later time by issuing the same command. 4. Installing the Files Note: If you are upgrading an existing system be sure to read Section 17.6 which has instructions about upgrading a cluster. To install PostgreSQL enter:

gmake install This will install files into the directories that were specified in step 1. Make sure that you have appropriate permissions to write into that area. Normally you need to do this step as root. Alternatively, you can create the target directories in advance and arrange for appropriate permissions to be granted. To install the documentation (HTML and man pages), enter:

gmake install-docs If you built the world above, type instead:

gmake install-world

This also installs the documentation. You can use gmake install-strip instead of gmake install to strip the executable files and libraries as they are installed. This will save some space. If you built with debugging support, stripping will effectively remove the debugging support, so it should only be done if debugging is no longer needed. install-strip tries to do a reasonable job saving space, but it does not have perfect knowledge of how to strip every unneeded byte from an executable file, so if you want to save all the disk space you possibly can, you will have to do manual work. standard installation provides all the header files needed for client application development as well as for server-side program development, such as custom functions or data types written in C. (Prior to PostgreSQL 8.0, a separate gmake install-all-headers command was needed for the latter, but this step has been folded into the standard install.) Client-only installation: If you want to install only the client applications and interface libraries, then you can use these commands:

gmake -C src/bin install gmake -C src/include install gmake -C src/interfaces install gmake -C doc install

src/bin has a few binaries for server-only use, but they are small. Registering eventlog on Windows: To register a Windows eventlog library with the operating system, issue this command after installation:

regsvr32 pgsql_library_directory/pgevent.dll This creates registry entries used by the event viewer. Uninstallation: To undo the installation use the command gmake uninstall. However, this will not remove any created directories. Cleaning: After the installation you can free disk space by removing the built files from the source tree with the command gmake clean. This will preserve the files made by the configure program, so that you can rebuild everything with gmake later on. To reset the source tree to the state in which it was distributed, use gmake distclean. If you are going to build for several platforms within the same source tree you must do this and re-configure for each platform. (Alternatively, use a separate build tree for each platform, so that the source tree remains unmodified.) If you perform a build and then discover that your configure options were wrong, or if you change anything that configure investigates (for example, software upgrades), then it's a good idea to do gmake distclean before reconfiguring and rebuilding. Without this, your changes in configuration choices might not propagate everywhere they need to.

<End: Excerpts from Postgresql Documentation>

</11.1> <11.2>

<Begin: .bash.profile vs .bashrc> .bash_profile vs .bashrc by Josh Staiger WHEN working with Linux, Unix, and Mac OS X, I always forget which bash config file to edit when I want to set my PATH and other environmental variables for my shell. Should you edit .bash_profile or .bashrc in your home directory? You can put configurations in either file, and you can create either if it doesn’t exist. But why two different files? What is the difference? According to the bash man page, .bash_profile is executed for login shells, while .bashrc is executed for interactive non-login shells. What is a login or non-login shell? When you login (type username and password) via console, either sitting at the machine, or remotely via ssh: .bash_profile is executed to configure your shell before the initial command prompt. But, if you’ve already logged into your machine and open a new terminal window (xterm) inside Gnome or KDE, then .bashrc is executed before the window command prompt. .bashrc is also run when you start a new bash instance by typing /bin/bash in a terminal. Why two different files? Say, you’d like to print some lengthy diagnostic information about your machine each time you login (load average, memory usage, current users, etc). You only want to see it on login, so you only want to place this in your .bash_profile. If you put it in your .bashrc, you’d see it every time you open a new terminal window. Mac OS X — an exception An exception to the terminal window guidelines is Mac OS X’s Terminal.app, which runs a login shell by default for each new terminal window, calling .bash_profile instead of .bashrc. Other GUI terminal emulators may do the same, but most tend not to. Recommendation Most of the time you don’t want to maintain two separate config files for login and non-login shells — when you set a PATH, you want it to apply to both. You can fix this by sourcing .bashrc from your .bash_profile file, then putting PATH and common settings in .bashrc.

To do this, add the following lines to .bash_profile:

if [ -f ~/.bashrc ]; then source ~/.bashrc fi

Now when you login to your machine from a console .bashrc will be called. <End: .bash.profile vs .bash.rc>

</11.2> <11.3>

Source: http://www.ghacks.net/2009/04/04/get-to-know-linux-the-etcinitd-directory/

<Begin: Understanding init.d directory>

Get To Know Linux: The /etc/init.d Directory If you use Linux you most likely have heard of the init.d directory. But what exactly does this directory do? It ultimately does one thing but it does that one thing for your entire system, so init.d is very important. The init.d directory contains a number of start/stop scripts for various services on our system. Everything from acpid to x11-common is controlled from this directory. Of course it’s not exactly that simple. If you look at the /etc directory you will find directories that are in the form rc#.d (Where # is a number reflects a specific initialization level – from 0 to 6). Within each of these directories is a number of other scripts that control processes. These scripts will either begin with a “K” or an “S”. All “K” scripts are run before “S” scripts. And depending upon where the scripts are located will determine when the scripts initiate. Between the directories the system services work together like a well-oiled machine. But there are times when you need to start or stop a process cleanly and without using the kill or killall commands. That is where the /etc/init.d directory comes in handy. Now if you are using a distribution like Fedora you might find this directory in /etc/rc.d/init.d. Regardless of location, it serves the same purpose. In order to control any of the scripts in init.d manually you have to have root (or sudo) access. Each script will be run as a command and the structure of the command will look like:

/etc/init.d/command OPTION Where command is the actual command to run and OPTION can be one of the following:

start stop reload restart force-reload

Most often you will use either start, stop, or restart. So if you want to stop your network you can issue the command:

/etc/init.d/networking stop Or if you make a change to your network and need to restart it, you could do so with the following command:

/etc/init.d/networking restart Some of the more common init scripts in this directory are:

networking samba apache2 ftpd sshd dovecot mysql

Of course there may be more often-used scripts in your directory – it depends upon what you have installed. The above list was taken from a Ubuntu Server 8.10 installation so a standard desktop installation would have a few less networking-type scripts. But what about /etc/rc.local? There is a third option that I used to use quite a bit. This option is the /etc/rc.local script. This file runs after all other init level scripts have run, so it’s safe to put various commands that you want to have issued upon startup. Many times I will place mounting instructions for things like nfs in this script. This is also a good place to place “troubleshooting” scripts in. For instance, once I had a machine that, for some reason, samba seemed to not want to start. Even afer checking to make sure the Samba daemon was setup to initialize at boot up. So instead of spending all of my time up front with this I simply placed the line:

/etc/init.d/samba start in the /etc/rc.local script and Samba worked like a charm. Eventually I would come back and trouble shoot this issue. Final Thoughts Linux is flexible. Linux is so flexible there is almost, inevitably, numerous ways to solve a single problem. Starting a system service is one such issue. With the help of

the /etc/init.d system (as well as /etc/rc.local) you can pretty much rest assured your service will start. <End: Understanding init.d directory>

</11.3> <End: Appendices> </11> <12> We appreciate your feedback so that we can improve TULIS Framework/Semantics as well as

improving the style and clarity of this IN. You may write to megatahmadsani@gmail.com </12>