The PostgreSQL project bills itself as the world’s most advanced open source database. Sun has long touted Solaris as a premier operating system platform so it makes sense to see the two together in the Solaris 10 distribution.

EnterpriseDB will provide Sun with custom training classes for their engineering and technical support teams on PostgreSQL. Sun can provide tech support for the database, and turn to Enterprise DB for additional support.

The real moneymaker will come from professional services and consulting, which EnterpriseDB can deliver for PostgreSQL to Sun or Sun’s clients who implement the database.

EnterpriseDB has built its Advanced Server product upon the foundation provided by the open source PostgreSQL database. PostgreSQL offers a number of advanced features; the project noted it is aware of production systems using PostgreSQL to manage in excess of 4 terabytes of data.

“PostgreSQL is in our company DNA,” said Andy Astor, chief executive officer of EnterpriseDB. “We have spent years enhancing PostgreSQL to create EnterpriseDB Advanced Server, and we understand the underlying PostgreSQL code better than any other company on the planet.

Solaris 10 now comes to customers under Sun’s Common Development and Distribution License. The OpenSolaris project manages Solaris 10 and other projects like the DTrace performance analysis and debugging tool; Apple recently announced DTrace would be part of the forthcoming Mac OS X Leopard distribution.

—
Tag:

Add to Del.icio.us | Digg | Yahoo! My Web | Furl

Bookmark WebProNews:

David Utter is a staff writer for WebProNews covering technology and business.

Love-arrangers eHarmony have a more than passing engagement with open source software. But it’s an open marriage, as eHarmony is not looking for open source solutions to its needs, but the best solutions.

A report on NewsForge cited eHarmony VP of engineering and operations on the topic of software choices.

Netcraft shows the domain resides behind a F5 Big-IP load balancer now, instead of reporting Linux as the server’s operating system. F5 would be an example of a “best solution” for hardware, due to its reputation for solid load balancing performance.

Linux of course represents one of several open source options eHarmony has made for its servers. Applications developed for eHarmony run on names that are very familiar to web developers, like Tomcat for handling Java Servlets and JavaServer Pages; JBoss for serving applications; and Apache as its web server of choice.

“It’s most of the stuff everyone is using,” Douglas said in the article. “Open source is not new to our company. We use it extensively, because the best product is often open source. We’re not zealots about open source, we just go out and look for what’s best.”

On the database side, eHarmony chose Oracle over robust open source options like PostgreSQL and Ingres, both of which offer serious relational database choices.

For developers who would like to get open source in the front door of their companies, where proprietary solutions may dominate the work landscape, Douglas offers some advice in the report.

“Just pick the right product. Usually the concern about open source that I’ve witnessed is, ‘how am I gonna get support?’ But even if you’re not paying for support there’s a ton of information out there. I would just find the best product for whatever I’m trying to do, and if that’s open source, there’s generally a company that will help you.”

—

Add to Del.icio.us | Digg | Yahoo! My Web | Furl

Bookmark WebProNews:

David Utter is a staff writer for WebProNews covering technology and business.

Like a number of rock bands, PostgreSQL reportedly has a significant following in Japan. By the project’s admission though, it may rate fifth in the US in popularity among database systems as of 2004.

MySQL receives a lot of press coverage, due to its ease of use and the prominent names of firms and agencies that have implemented it for their operations. PostgreSQL offers some powerful features in its product that developers may wish to consider.

Multi-version concurrency control has been part of PostgreSQL for some time. It has native programming interfaces for a variety of languages: C/C++, Java, Perl, Python, Ruby, ODBC, and Tcl.

The PostgreSQL database is open source, fully ACID compliant, includes most SQL92 and SQL99 data types, and can support storage of multimedia objects. With the growth of broadband adoption in the US and the world, that could be an important consideration for web application developers.

Documentation for PostgreSQL exists in online form and by PDF download in US or A4 page formats. Since the current PDF runs 12.1 MB in size, users may wish to try out the online version first.

Users coming in from other database systems can learn more about PostgreSQL within those pages. For example, the project lists advantages of working with the PL/pgSQL language:

Some developers, particularly ones in a corporate environment, may favor PostgreSQL’s BSD licensing over MySQL’s GPL terms. (Please note that MySQL does offer commercial licenses for sale through MySQL AG). BSD licensed code can be taken and incorporated into non-open source projects, and presents a more business-friendly approach.

—
Tag:

Add to Del.icio.us | DiggThis | Yahoo! My Web | Furl

Bookmark WebProNews:

David Utter is a staff writer for WebProNews covering technology and business.

MySQL has an extensive presence online, with Yahoo and NASA using it for their services. PostgreSQL has its place with Red Hat and Cisco; both databases have many more users than those listed.

With those high-quality databases available for free, developers can pick and choose which one will best fulfill the requirements of their web applications. Both products offer ACID-compliance and transaction support among their features.

Despite the availability of PostgreSQL and MySQL, the powerhouses of corporate databases believe they can hook developers with versions of their mainstream database products by providing lite versions of them for free, too.

Various limitations, like caps on how much data can be supported or only using one processor on a multi-processor system, keep the lite versions from matching their full price counterparts. Companies hope to demonstrate that their feature sets will prove the deciding factor in choosing a proprietary system over an open source one.

Oracle began offering its out-of-beta version of 10g Express Edition earlier this year. IBM noted how developers familiar with MySQL can take that knowledge to DB2 Express-C.

Microsoft likewise made SQL Server Express available for its users. That product also integrates with the free Visual Web Developer Express suites for creating web applications.

While all of the Express database editions from the big tech companies have been designed to bring users along from at-home hobbyists to at-work product evangelists, they do provide an inside look at how those databases could benefit web development on a larger scale.

—

Add to | DiggThis | Yahoo! My Web | Furl It

Bookmark WebProNews –

David Utter is a staff writer for WebProNews covering technology and business.

If the connection to a database is not secure, there can be irrevocable damages done to the company or to the owner of the database. And of course, you know the net result – a substantial loss of money and the loss of creditability with the clients (More so, if the company happens to be a bank or a credit card company). So, security is one of the top most priorities even in the database world.

Let’s discuss some of the ways in which we can authenticate users to ensure secure transactions in PostgreSQL. In this article, I will talk about client authentication. Encryption and Access control lists are some of the other key security issues. If you haven’t heard these terms so far, don’t panic. You’ll learn them in a short while.

Client authentication is one of the key features of PostgreSQL. With out it, either we sacrifice remote connectivity to the databases or allow just about anybody access to our most important data. PostgreSQL supports several types of authentication. It’s up to the database administrator to choose one of them.

Host-based client access is specified in the configuration file pg_hba.conf. It’s generally located in the PostgreSQL data directory (/usr/local/pgql/data/– Generally the environment variable $PGDATA is set to this path). And it’s installed automatically when you install PostgreSQL with the initdb command. I don’t discuss initdb in this article. You may consult the man pages for more information on initdb.

The pg_hba.conf file controls: 1) Which hosts are allowed to connect 2) How users are authenticated on each host. 3) Databases accessible by each host

I’ll discuss each of these in just a minute. The configuration file is read on postmaster startup and when the postmaster receives a SIGHUP. Postmaster is generally the server in a PostgreSQL database system.

Sample pg_hba.conf file on a Linux box

PostgreSQL HOST-BASED ACCESS (HBA) CONTROL FILE

type	database	ip_address	mask	auth_type	auth_argument
local	all			trust
host	all	127.0.0.1	255.255.255.255	trust
host	template1	192.168.93.0	255.255.255.0	ident	sameuser
host	template1	192.168.12.10	255.255.255.255	md5
host	all	192.168.54.1	255.255.255.255	reject
host	all	0.0.0.0	0.0.0.0	krb5
local	sameuser			md5
local	all			md5	admins

Let me discuss what each of these entries means.

The type field tells us what the type of the connection is. There can be three different kinds of connections. They are: a) host b) hostssl and c) local

Records with the type field set to “host” indicate what different networked hosts can connect to the database. A record with “hostssl” type is similar, but adds the additional information, that the connection is over a secure socket layer (SSL). A “local” type tells that the connection is from the local host via a UNIX domain socket.

The second field is the database name. It can be one of the following: a) the name of a PostgreSQL database b) “all” to indicate all databases c) “sameuser” to allow access only to databases with the same name as the connecting user

The third and fourth fields are the IP address and the subnet mask of the host from which the connection is sought.

The fifth field is what is the most important to us. It is the authentication type field. As I said earlier, PostgreSQL supports different types of authentication.

Some of them are: a) Crypt b) Md5 c) Kerberos d) PAM e) Ident f) Password authentication and g) Trust

Here is the definition of each of the above mentioned authentication types. These definitions are taken from the config file itself.

trust: No authentication is done. Any valid username is accepted, including the PostgreSQL superuser. This option should be used only for hosts where all users are trusted.

password: Authentication is done by matching a password supplied in clear by the host. If no AUTH_ARGUMENT is used, the password is compared with the user’s entry in the pg_shadow table.

If AUTH_ARGUMENT is specified, the username is looked up in that file in the $PGDATA directory. If the username is found but there is no password, the password is looked up in pg_shadow. If a password exists in the file, it is used instead. These secondary files allow fine-grained control over who can access which databases and whether a non-default password is required. The same file can be used in multiple records for easier administration. Password files can be maintained with the pg_passwd(1) utility. Remember, these passwords override pg_shadow passwords.

md5: Same as “password”, but the password is encrypted while being sent over the network. This method is preferable to “password” except for pre-7.2 clients that don’t support it. NOTE: md5 can use usernames stored in secondary password files but ignores passwords stored there. The pg_shadow password will always be used.

crypt: Same as “md5″, but uses crypt for pre-7.2 clients. You can not store encrypted passwords in pg_shadow if you use this method.

ident: For TCP/IP connections, authentication is done by contacting the ident server on the client host. Remember, this is only as secure as the client machine. On machines that support Unix-domain socket credentials (currently Linux, FreeBSD, NetBSD, and BSD/OS), this method also works for “local” connections.

AUTH_ARGUMENT is required: it determines how to map remote user names to Postgres user names. The AUTH_ARGUMENT is a map name found in the $PGDATA/pg_ident.conf file. The connection is accepted if that file contains an entry for this map name with the ident-supplied username and the requested Postgres username. The special map name “sameuser” indicates an implied map (not in pg_ident.conf) that maps each ident username to the identical PostgreSQL username.

krb4: Kerberos V4 authentication is used. Allowed only for TCP/IP connections, not for local UNIX-domain sockets.

krb5: Kerberos V5 authentication is used. Allowed only for TCP/IP connections, not for local UNIX-domain sockets.

pam: Authentication is passed off to PAM (PostgreSQL must be configured –with-pam), using the default service name “postgresql” – you can specify your own service name, by setting AUTH_ARGUMENT to the desired service name. reject: Reject the connection. This is used to reject certain hosts that are part of a network specified later in the file. To be effective, “reject” must appear before the later entries.

Here is a sample pg_ident.conf file taken from the Linux box.

Sample pg_ident.conf file

PostgreSQL IDENT-BASED AUTHENTICATION MAPS
This file controls ident-based authentication. It maps ident usernames to their corresponding PostgreSQL usernames. Entries are grouped by map name. Each record consists of three fields.

o map name
o ident username
o PostgreSQL username

It is read on postmaster startup and when the postmaster receives a SIGHUP. If you edit the file on a running system, you have to SIGHUP the postmaster for the changes to take effect. For example, the following entry equates user “james” on a remote system to PostgreSQL user “guest” in the map named “phoenix”: MAP IDENT PGUSERNAME phoenix james guest “phoenix” can now be used by an “ident” record in $DATA/pg_hba.conf. Multiple maps may be specified in this file and used by pg_hba.conf. Note that it is possible for a remote user to map to multiple PostgreSQL usernames. The PostgreSQL username specified at connection time controls which one is used. If all ident usernames and PostgreSQL usernames are the same, you don’t need this file. Instead, use the special map name “sameuser” in pg_hba.conf.

Hope your patience did not run out reading the files above. I am sure you realized how simple it is to make a map in our pg_ident.conf file and use it in the pg_hba.conf file for authentication.

Let’s now make a map of our own. MAP IDENT PGUSERNAME mymap mike guest

The above entry maps the user ‘mike’ on the remote machine to the user ‘guest’ on the machine running the PostgreSQL server. Now we can use this map to make an entry in the pg_hba.conf file like this:

type database ip_address mask auth_type auth_argument

host all 63.170.212.30 255.255.255.0 ident mymap

That says, any user connecting from a machine with IP address 63.170.212.30 and subnet mask 255.255.255.0 is to be authenticated by using the map ‘mymap’ in pg_ident.conf file. Very simple, isn’t it?

That is about all for authentication in PostgreSQL. Hope you enjoyed the article. For more information on authentication, encryption and access control lists, please visit the links provided in the resources section. Have fun reading…

Jay Fougere is the IT manager for the iEntry network. He also writes occasional articles. If you have any IT questions, please direct them to Jay@ientry.com.