Nope... it isn't just you...

Post #101,235

5/10/03 8:56:19 PM

An MTA is required to deliver mail for maintenance and notices of porblems and such for postmaster to work properly.

Since Courier is/was the first one in the "LIST" of MTAs it got the bonus job of being default. Courier is also very simple and very "umm secure"... light and not much known in the way of exploits, but the way it is setup by default (just hitting enter) it acts as a local delivery only with forwarding to a smarthost without a "smarthost" to send to for non-local mail.

So, no you didn't just see it. Typically most Database machines have some sort of MTA already installed as part of the prep work for the DB install. Since Mike handen't setup an MTA, it did it.

Also, the question I really asked Ross was (but not in these verbose, layed out with a specific ruleset, directions. Whihc I had hoped I didn't NEED to do):

Let's say you HAVE to stay on the version of Postgresql you have installed now, the version you have installed now has one feature your WHOLE PRODUCT DEVELOPMENT depends on and the newer versions dropped this feature for a DIFFERENT one to do the function differently. BUT, being told from higher up (IOW the PHBs) you "need" to update your system (for whatever reason) to the Latest greatest version of said distribution. Can you using the automagic system tools completely upgrade the system from one major release to another without upgrading to a newer version of Postgresql, all whilst keeping the system running and live DOING it's function?

Summary:
1. Postgresql version MUST not change, nor can the build be differently compiled or built.
2. The CEO want's to brag and demands the OS be updated to latest "FOO" version of "BAR" distribution.
3. Use ONLY the "system package management tools" GUI or otherwise (YaST == SuSE, RPM == RedHat/Mandrake, APT/DPKG == Debian, emerge == Gentoo, etc...)
4. Keep the system up and running PERFORMING it's service or function while being updated
5. Do this without breaking your system.
6. Get it done in a reasonable fashion.
7. Manage the problem's as they occur inline with the upgrade without a break in the upgrade, therby not possibly having an UNUSEABLE/UNBOOTABLE system in the process.
8. Recover from a critical/fatal issue, requiring a break in the upgrade to fix the issue and continue from where you were
9. Go home at a decent time.

Please elucidate on this Ross or anyone else. Dweebian need not respond... unless they wanna.

[link\|mailto:greg@gregfolkert.net\|greg] - IT Grand-Master for Anti-President
[link\|http://www.iwethey.org/ed_curry/\|REMEMBER ED CURRY!]

THEY ARE WATCHING YOU.
The time has come for you to take the last step.
You must love THEM.
It is not enough to obey THEM.
You must love THEM.

PEACE BEGETS WAR, SLAVERY IS FREEDOM, STRENGTH IN IGNORANCE.

Post #101,261

by deSitter

5/11/03 2:29:23 AM

Re: Nope... it isn't just you...

1) Thanks for the dig - I can't read your mind.

2) Any system that has detailed dependency requirements such as you listed will need "hand" administration, in some form. From working very closely with SuSE 6,7, and 8, I can tell you that it is tightly delivered - so system dependencies are extremely well-handled. This I think is the Linux incarnation of good German engineering practice.

Now, for your issues:

1. Postgresql version MUST not change, nor can the build be differently compiled or built.

You pause the update to manually deselect anything that would break the DB. If something else you are trying to install *requires* a new version of the DB, the installer will inform you and you will have the choice of living without that, or forcing the install of it (taking chances). The key point here is the skill of the SuSE staff at identifying dependencies. I've seen numberless tweaks that SuSE makes of some or another package - in good GPL form - in order that it can live under YaST and its modules.

2. The CEO want's to brag and demands the OS be updated to latest "FOO" version of "BAR" distribution.

If you know that will break something, tell him, and if he insists, show him you weren't kidding.

3. Use ONLY the "system package management tools" GUI or otherwise (YaST == SuSE, RPM == RedHat/Mandrake, APT/DPKG == Debian, emerge == Gentoo, etc...)

4. Keep the system up and running PERFORMING it's service or function while being updated

I expect massive uptime on my x225. I'm sure I'll be tweaking it. I don't forsee big issues.

5. Do this without breaking your system.

I've had issues with hardware on Linux, but I've never had issues with SuSE administration. It started out good and just gets better, and is CONSISTENT across big version changes (at least since v.6).

6. Get it done in a reasonable fashion.

7. Manage the problem's as they occur inline with the upgrade without a break in the upgrade, therby not possibly having an UNUSEABLE/UNBOOTABLE system in the process.

The only times I ever destroyed a system like that were a) forgetting to run LILO b) deleting the wrong kernel image after an upgrade - whatever distribution, you should protect yourself against stupidity (like deleting bash.bashrc, which I did today).

8. Recover from a critical/fatal issue, requiring a break in the upgrade to fix the issue and continue from where you were

SuSE simply does not break during installs, and you can do a "manual" install where every action is run past you. But, it's always possible to screw something up, right? All I can say is, I've used admin tools on AIX, Sun, HP, and Digital, and even going back to Apollos and CRDS, and SuSE has the best administrative interface of all of them.

9. Go home at a decent time.

One hopes.

-drl

Post #101,301

by folkert

5/11/03 3:58:00 PM

Points completely missed again Ross.

Answer the questions. Not what your feeling is.

I asked specific questions, Do you need me to expanded the detail to the point of childishness? If you could just ANSWER those questions, it'd be grand.

Unless you can't.

And we are Dwebians, Snobbians, Deb-O-Snobs for a reason. That, which you'll never quite understand. Mainly due to your slant of US vs. THEM. Debian goes to the CORE of what OSS really means. It goes so far as to HELP those projects and packages associated to it's Linux flavor as to comform to a set of guidelines. RPM is a similar set, as to HOW to package, but Debian goes a bit further, stating not only HOW to package but HOW that package is submitted and HOW and WHERE the files associated with that package needs to install to and how it's to be managed. also, the quality Control that packages go through. Options in something like Postgreql, are usually packaged seperately as they are options. They are compiled at the same time and packaged at the same time, but made seperate from the Primary.

[link\|mailto:greg@gregfolkert.net\|greg] - IT Grand-Master for Anti-President
[link\|http://www.iwethey.org/ed_curry/\|REMEMBER ED CURRY!]

Welcome to IWETHEY!