Re: [GENERAL] Linux distro

[Brian Mathis]

On 8/2/07, Andrej Ricnik-Bay <[EMAIL PROTECTED]> wrote:
> On 8/3/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
>
> > they do, but experience has shown it is prudent to be able to
> > administrate the hardware directly from the box.
>
> I'm curious:  which aspect of hardware administration
> on a Linux box would require X (to be running)?  If I *really*
> needed applet such-and-such I could still run it easily, with
> less overhead and w/o the X server even being installed on
> the big iron from my desktop ...
>
> ssh -X [EMAIL PROTECTED] whizbangGUItool
>
[...]
> Cheers,
> Andrej

There is of course no *requirement* for this to be the case, but one
must make concessions for the fact that not everyone is at the same
level of administration.  To make Linux more accessible, a GUI is
added for those people.  Those people are just as smart and equally
talented, but simply may not have the time to learn every command line
detail to get a server up.

While I agree that one can also use ssh and a remote X display (and is
personally how I would do it, if not just pure command line), it is
not that much of a stretch to understand that someone else's
circumstances may not allow this without more additional setup which
requires more time.

Also, while the usual runlevel for a system would be 3, keeping a
system at runlevel 5 would not realistically use more resources.  When
the system starts up, it will load the X server and xdm only (not
gnome or anything else until someone logs in), and when not used all
of that will get paged out to disk, so all it is taking up is a
fraction of the CPU to make the login cursor blink.  Any default
screensaver will basically just blank the screen.

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [GENERAL] Linux distro

[Brian Mathis]

On 8/1/07, Douglas McNaught <[EMAIL PROTECTED]> wrote:
> Joseph S <[EMAIL PROTECTED]> writes:
>
> > My small gripes about Ubuntu are:
> >   1) rpm, for all its faults, is still better than using apt
>
> You *must* be joking.  In Debian and Ubuntu, I've never had a tenth of
> the dependency hell that you regularly hit with RPMs (though yum has
> improved things somewhat).  Besides 'apt' and 'rpm' aren't directly
> comparable--'apt' is a wrapper around 'dpkg', which is the direct
> equivalent of 'rpm'.
>
> -Doug
>

Please don't start this.  These issues are exactly why one should be
looking at an ENTERPRISE OS for a server.  Fedora, ubuntu, etc... are
not enterprise OSes, and any discussion of such issues are certainly
off-topic for this mailing list.  An enterprise OS has all of the
dependency issues ironed out already.

Incidentally, I really think that all of the "apt lovers" out there
jumped to Debian in the days before tools like yum existed, and have
not been paying attention to the changes made since.  You are correct
that yum handles most of the dependency issues, and it is certainly on
par with apt in any modern system.

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [GENERAL] Linux distro

[Brian Mathis]

On 8/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I bought a Dell server and I am going to use it for installing PostgrSQL
> 8.2.4. I always used Windows so far and I would like now to install a
> Linux distribution on the new server. Any suggestion on which distribution
> ? Fedora, Ubuntu server, Suse or others?
>
> Thanks in advance,
> Paolo Saudin

Be careful when rolling something out you are not familiar with.  You
really shouldn't go into production with an OS you don't know.

As for Linux, using an *Enterprise OS* is the ONLY type of OS you
should use.  Others may say that they "never had any problems" with
non-enterprise OS versions, but they have missed the point.  An
enterprise OS is something that is tried-and-true, has long term
support, and has been proven to be stable and working.  That basically
leaves RedHat Enterprise (and it's clones) and some versions of SuSE.
Ubuntu claims to have a "long term support" version, but it hasn't
been around long enough to be proven.

My recommendation is to go with CentOS, which is the best clone of
Redhat enterprise (redhat even works with them behind the scenes).
They release updates within 1-7 days of when an update comes out from
redhat, and it has been around a long time; tried and true.

Another important point to make is that if you plan on having more
servers in the future, you really want to have the same OS on
everything.  It's not a good idea to try one OS here, then try another
OS there.  That's fine for your desktop or for doing research, but is
an unsuitable strategy when deploying things in production.

Ubuntu, fedora, and many of the others are "desktop" linuxes, and are
not suitable for use on a server.

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [GENERAL] Encrypted column

[Brian Mathis]

On 6/5/07, Marko Kreen <[EMAIL PROTECTED]> wrote:

On 6/5/07, Marko Kreen <[EMAIL PROTECTED]> wrote:
> both md5 and sha1 are actually easier to bruteforce than
> the old DES-based crypt.

If this statement seems weird - the problem is the speed.
MD5 and SHA1 are just faster algorithms than des-crypt.

And there's nothing wrong with fast general-purpose algorithms,
as long their cryptographic properties hold.  Starting from
20-30 bytes the bruteforce is really not an option.

But if you have under 10 bytes (let be honest - you have
6 bytes...) the speed start to matter, because it is possible
on random laptop to simply try all combinations.

--
marko



pgcrypto also supports md5, so I'm not sure what you're referring to
here.  As I already mentioned, *salting* before you hash is a very
important step.  I'm not sure if you saw that in my post.  Without a
salt, it's trivial to generate a list of all combinations of md5'd
strings and their results, up to reasonable lengths.  Then it would be
very simple to look up each hash and get the original text.  With a
salt, you need to generate all possible md5s for all possible salts --
a much harder task.

In any case, pgcrypto seems to be a nice and full featured tool, so
one should use that instead of rolling their own.

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [GENERAL] Encrypted column

[Brian Mathis]

On 6/5/07, Marko Kreen <[EMAIL PROTECTED]> wrote:

On 6/5/07, Tino Wildenhain <[EMAIL PROTECTED]> wrote:
> Ranieri Mazili schrieb:
> > Hello,
> >
> > I need to store users and passwords on a table and I want to store it
> > encrypted, but I don't found documentation about it, how can I create a
> > table with columns "user" and "password" with column "password"
> > encrypted and how can I check if "user" and "password" are correct using
> > a sql query ?
>
> Passwords are usually not encrypted but hashed instead. A common hash
> function is available in postgres w/o any additional extension:
>
> md5()
>
> The rule is, if two hashes compare equal, then the original data must
> be equal (yes, there are chances for collisions, but practically very
> low. See also sha1 and friends in the pgcrypto contrib module)

Both md5 and sha1 are bad for passwords, no salt and easy to
bruteforce - due to the tiny amount of data in passwords.

Proper ways is to use crypt() function from pgcrypto module.
Due to historical accident is has bad name which hints at
encryption, actually its only purpose is to hash passwords.
Read more in pgcrypto doc.

--
marko



If you salt them yourself, there's no problem with md5 or sha1, and
they are arguably more secure than the old "crypt" call.  Most modern
linuxes use md5 for password storage.

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [GENERAL] Encrypted column

[Brian Mathis]

On 6/5/07, Tino Wildenhain <[EMAIL PROTECTED]> wrote:

Ranieri Mazili schrieb:
> Hello,
>
> I need to store users and passwords on a table and I want to store it
> encrypted, but I don't found documentation about it, how can I create a
> table with columns "user" and "password" with column "password"
> encrypted and how can I check if "user" and "password" are correct using
> a sql query ?

Passwords are usually not encrypted but hashed instead. A common hash
function is available in postgres w/o any additional extension:

md5()

The rule is, if two hashes compare equal, then the original data must
be equal (yes, there are chances for collisions, but practically very
low. See also sha1 and friends in the pgcrypto contrib module)

Regards
Tino



Remember, you would also want to add some sort of salt before you ran
the hash, otherwise your password list is vulnerable to a simple
brute-force attack.

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [GENERAL] Dependency conflicts on CentOS 4.4

[Brian Mathis]

On 1/4/07, Tony Caduto <[EMAIL PROTECTED]> wrote:


Gunnar Wagenknecht wrote:



Do I need to look for a different 'perl-DBD-Pg' that doesn't depend on



> 'libpq.so.3' or should 'libpq.so.3' be provided by
> 'postgresql-libs-8.2.0-2PGDG.i686.rpm'?
>
Just make a symbolic link from the shipped libpq.so.5 to libpq.so.3 and
it should work.

Yum kind of stinks because you can't do a --nodeps or force.
You might want to download the perl dbd rpm and install manually without
Yum.

Later,

--
Tony Caduto



While this may work, it pretty much defeats the purpose of using rpm and yum
to manage your packages.  Devrim's suggestion is really the best way to go
(as are most of his suggestions).  I have used the compat rpm before, and it
works like a charm.

Usually nodeps and force are there for a reason, defeating them is usually
not what you want.

Re: [GENERAL] A query planner that learns

[Brian Mathis]

On 10/17/06, Madison Kelly <[EMAIL PROTECTED]> wrote:
Brian Mathis wrote:> I also am NAL, but I know enough about the patent system (in the US) to> know that ignorance *IS* a defense.  If you are ignorant of the patent,> you only have to pay the damages.  If you knew about the patent and did
> it anyway, you have to pay *triple* damages.  Ignorance will save you> lots of money.>> You may not like it, but that's the way it is.>I got that part. :) If you _do_ end up in court, plausible deniability
helps.My position though is that it is better, in the long term, to be awareof the patents and take the time to work around them so that *no*damages need to be paid. Or, as might be that chance in this case, to
get a written "okay" from the patent holder for the use of the methodsprotected by the patent in a given program.Colour me funny, but wouldn't staying out of the courts in the firstplace not be the best option?
MadiYes, good idea :)

Re: [GENERAL] A query planner that learns

[Brian Mathis]

On 10/17/06, Madison Kelly <[EMAIL PROTECTED]> wrote:
AgentM wrote:> Alvaro's advice is sound. If the patent holder can prove that a> developer looked at a patent (for example, from an email in a mailing> list archive) and the project proceeded with the implementation
> regardless, malice can been shown and "damages" can be substantially> higher. You're screwed either way but your safest bet is to never look> at patents.>> Disclaimer: I am not a lawyer- I don't even like lawyers.
Nor am I a lawyer, but I still hold that hoping "ignorance" will be adecent defense is very, very risky. In the end I am not a pgSQLdeveloper so it isn't in my hands either way.Madi
I also am NAL, but I know enough about the patent system (in the US) to know that ignorance *IS* a defense.  If you are ignorant of the patent, you only have to pay the damages.  If you knew about the patent and did it anyway, you have to pay *triple* damages.  Ignorance will save you lots of money.
You may not like it, but that's the way it is.

Re: [GENERAL] customizing pg_dump together with copy.c's DoCopy function

[Brian Mathis]

pg_dump by default dumps to STDOUT, which you should use in a pipeline to perform any modifications.  To me this seems pretty tricky, but should be doable.  Modifying pg_dump really strikes me as the wrong way to go about it.  Pipelines operate in memory, and should be very fast, depending on how you write the filtering program.  You would need to dump the data without compression, then compress it coming out the other end (maybe split it up too).  Something like this:
    pg_dump | myfilter | gzip | split --bytes=2000M - mydump.Also, you can't expect to have speed if you have no disk space.  Reading/writing to the same disk will kill you.  If you could set up some temp space over NFS on the local network, that should gain you some speed.
On 11 Jul 2006 08:43:17 -0700, [EMAIL PROTECTED] <[EMAIL PROTECTED]
> wrote:> > Is it possible to compile-link together frontend pg_dump code with
> > backend code from copy.c?>> No.  Why do you think you need to modify pg_dump at all?>pg_dump and pg_restore provide important advantages for upgrading acustomer's database on site:
They are fast. I want to minimize downtime.They allow compression. I often will have relatively little free diskspace to work with.My concept is "customized dump", drop database, create new schema
database, "customized restore".My upgrade requires many schema and data content changes. I've triedusing standard SQL statements in perl scripts to do all of it, but evenwith no indexes on inserts, later creating indexes for the lookup work,
and every other optimization I know of, a 100gb database requiresseveral days to turn our old database into a new one. I was hoping thatI could modify the speedy pg_dump/pg_restore utilities to make thesechanges "on the fly". It gets tricky because I have to restore some of
the data to different tables having varying schema and also change thetable linking. But this is all doable as long as I can "massage" theSQL statements and data both when it goes into the dump file and when
it is getting restored back out.Or am I trying to do the impossible?-Lynn

[GENERAL] Problem with postgresql-docs-8.1.4-1PGDG.i686.rpm

[Brian Mathis]

I am trying to upgrade my installation from 8.1.3 to 8.1.4, and when I try to upgrade the postgresql-docs package, I am getting the following error from 'rpm -Uvh':error: postgresql-docs-8.1.4-1PGDG.i686.rpm
: MD5 digest: BAD Expected(a6f3196317b296ef555f47f343a6871b) != (b9dcbf1533565efb9d629e25a4224906)I have verified the md5sum of the package against that listed in the file MD5SUM, and it returns OK.I am using binary packages from this directory on the ftp:
    binary/v8.1.4/linux/rpms/redhat/rhel-as-4/ My server is a CentOS 4.3 installation with all updates applied.Is anyone else seeing this?Thanks.

Re: [GENERAL] libpq version in rpm packages

[Brian Mathis]

Thanks for that rpm.

I noticed that the x86_64 version of the compat libs installs the files
in /usr/lib, while the x86_64 postgresql-libs rpm uses
/usr/lib64.  Is there are reason for that?  Otherwise, I'd
prefer to keep all the 64bit libs in lib64.
On 11/9/05, Devrim GUNDUZ <[EMAIL PROTECTED]> wrote:
We have a compat RPM to solve that issue:http://developer.postgresql.org/~devrim/rpms/compat/There are RPMs for x86 and x86_64; as well as a srpm. This RPM includes
libs from older PostgreSQL versions and these libs satisfy thedependencies.Regards,- --Devrim GUNDUZKivi Bilişim Teknolojileri - http://www.kivi.com.tr

[GENERAL] libpq version in rpm packages

[Brian Mathis]

I just set up a new server and would like to use rpms to manage the
software on this one.  I've done the compile from source thing
most of the time, but over time it seems to get messy.

I'm using CentOS 4.2, which only has packages for postgres 7.4, but I
very much want to use 8.1.  I installed the 8.1 RPMs, but when I
try to install packages like perl-DBD-Pg, or php-pgsql, rpm complains
because they want libpq.so.3, and postgres 8.1 comes with libpq.so.4.

Does anyone have a workaround for this?  I've thought about
forcing the rpms to install, or even installing the postgres libs from
7.4.

Suggestions?

Thanks.

Re: [GENERAL] SHA1 authentication

[Brian Mathis]

On 10/27/05, Bruno Wolff III <[EMAIL PROTECTED]> wrote:
On Mon, Oct 24, 2005 at 11:33:50 +0200,  Martijn van Oosterhout  wrote:>> By all means, submit a patch but there's no real hurry right now. We
> should probably move straight to something more secure anyway, maybe> SHA-256 or something.This makes more sense. There is little point in going to the effort tochanging to SHA-1 only to change again later.
There isn't any hurry to change now, so it might be better to wait untilthe next group of hash functions is designed, built on lessons learned fromthe attacks against MD5 and SHA-1.
It might be a good step to go through and figure out what needs to be
changed, then implement a plugin type system to reduce the need for
changes when the next generation of hashes gets "broken".  It
might even allow for authentication to external sources, like LDAP or
some other plugin.

Re: [GENERAL] Select all invalid e-mail addresses

[Brian Mathis]

On 10/20/05, Douglas McNaught <[EMAIL PROTECTED]> wrote:
> It performs a MX-lookup, which IMHO is the best way to check for validity.But that's expensive and slow, and doesn't tell you whether the userpart of the address is valid (and in general, there's no way to
determine that short of actually sending a message).  So what's thepoint?-Doug
That's why I think the better term for this is "well formed". 
"Validity" can only be determined by sending to it, but you can tell if
an address at least conforms to the specs programmatically.  In
the end, when talking about a "valid" address in this context, that is
what most people are talking about.

The point is to weed out malformed email addresses, just like you would
enforce any other data formatting standards in other types of data.

[GENERAL] PG 8.0.4, Centos and 64 bit

[Brian Mathis]

Hello,

I am getting ready to install a new server for a new postgres install,
and I'm looking for a little advice.  The server is a dual opteron
system, and I plan on using CentOS 4.1 x86_64 for the OS.  I'm
going to do my best to make it s pure 64 bit system.

Does anyone have any experience running this configuration?  Does postgres play nice on centos 4.1?  x86_64?

Also, are there any rpms for this setup?  I looked in the binary section for rpms, but all the directories were empty.

Thanks.