02-07-2020
Normally if we are making upgrades to mission critical applications in 100s of servers in a large organization with a risk management team we should notify them if if we plan any upgrades which may cause an outage.
You should test in a test bed, make a plan, identify the risks and notify your risk management team.
Upgrading the core "mission critical" application on 200-300 web servers requires planning and team work.
What happens if you make a mistake and bring down the application(s)? Do you want your organization to be caught off guard when customers are calling in, angry their service is down?
You have described a major infrastructure upgrade. You certainly do not want to upgrade with YUM over a manually installed configuration until you have completed tested this idea in a test bed, insure you have backups of each application and database before hand, etc. In other words, you need a plan in coordination with your IT risk management team, customer service, etc.
This is how we work as IT professionals.
9 More Discussions You Might Find Interesting
1. Programming
Is there anyone who still uses CMI to connect to the legacy system , my c applications do uses the binaries and libraries for using the CMI functionality but i do not have access to the original source code , and since this is a very old stuff , i just could not get any source to get to knwo the... (0 Replies)
Discussion started by: dino_leix
0 Replies
2. IP Networking
Hello friends I'm running Redhat 9.0 with linux kernel 2.4.20-8 & have iptables version 1.2.7a & encountering a problem that I narrate down.
I need to apply patch to my iptable and netfilter for connection tracking and load balancing that are available in patch-o-matic distribution by netfilter.... (0 Replies)
Discussion started by: Rakesh Ranjan
0 Replies
3. Red Hat
Hello,
I am using Redhat Linux Enterprise 4 AS.
To upgrade NFS, I had to browse the internet and finally I got the latest rpm https://rhn.redhat.com/errata/RHBA-2005-727.html
That was a time-consuming procedure. On Solaris, I am used to go to sunfreeware.sun.com and download the latest... (3 Replies)
Discussion started by: melanie_pfefer
3 Replies
4. Programming
I need help locating the tables that hold the demograhic data in this system on an AIX box. Does anyone know the path? (0 Replies)
Discussion started by: Chelcye
0 Replies
5. Slackware
Hi!
Let me introduce a project for find and download Slackware packages and browse Slackware repositories.
The site provides following features:
* Large, daily updated database with RPM, DEB, TGZ, TXZ packages for well-known repositories of the Slackware, Fedora, CentOS, RHEL, Debian,... (2 Replies)
Discussion started by: lystor
2 Replies
6. Solaris
I have a Solaris 10 OS having kernal patch level 138888-03 on several servers but recenlty I upgraded it into 142900-12 on some T-Series servers & v890 server after install them my syslog is increasing at a rate of 1GB on average on all servers . I believe its a bug, can somebody help me in... (1 Reply)
Discussion started by: sb200
1 Replies
7. What is on Your Mind?
Watched it. Major disappointment. (10 Replies)
Discussion started by: ni2
10 Replies
8. Ubuntu
Hi folks,
Ubuntu 9.04
I have an old box not running for years. I just dig it out from the store room. On running;
$ sudo aptitude update
......
......
Err http://hk.archive.ubuntu.com jaunty/main Packages
404 Not Found
Err http://hk.archive.ubuntu.com jaunty/restricted Packages
... (1 Reply)
Discussion started by: satimis
1 Replies
9. Solaris
Hi Folks,
Just a quick question here, about Legacy Zones. Well more about how to determine if you are actually in one, on logging into a legacy zone - is there a quick way of checking that?
Regards
Gull04 (7 Replies)
Discussion started by: gull04
7 Replies
LEARN ABOUT DEBIAN
ovdb_init
OVDB_INIT(8) InterNetNews Documentation OVDB_INIT(8)
NAME
ovdb_init - Prepare ovdb database for use
SYNOPSYS
ovdb_init ["-u"|"-r"]
DESCRIPTION
This command must be run before any other process can access the overview database. It performs the following steps:
1. Creates the database environment, if necessary
2. If the database is idle (and if the "-u" option is not specified), it performs a normal recovery. The recovery will remove stale
locks, recreate the memory pool cache, and repair any damage caused by a system crash or improper shutdown.
3. If the "-u" option is specified, it performs any necessary upgrades to the database. See the UPGRADING section below.
4. Starts the DB housekeeping processes (ovdb_monitor) if they're not already running. (Unless the "-r" option is specified).
5. Starts the ovdb readserver (ovdb_server) processes if readserver in ovdb.conf is true, and if they are not already running. (Unless
the "-r" option is specified).
Returns exit status of 0 if all steps were completed successfully. In the event of an error, messages are written to syslog and/or stderr.
If a recovery was attempted but it failed, the database may be damaged beyond repair, requiring a rebuild with makehistory(8).
This command is normally invoked automatically by rc.news(8).
It is OK to run this command multiple times.
OPTIONS
"-r"
Perform recovery only. "ovdb_monitor" is not started.
"-u"
Perform any needed upgrades. Recovery is not attempted. "ovdb_monitor" is started if the upgrade succeeded.
UPGRADING
There are two situations in which the database will need to be upgraded:
o You upgrade the Berkeley DB library to a newer version, for example from 2.7.7 to 3.1.17. In this case, the Berkeley DB db->upgrade()
method is used.
o You upgrade ovdb to a newer major version; i.e., ovdb-1.0 to ovdb-2.0.
In both of these cases, the database is upgraded in-place; and the upgrade can not be undone. Do not interrupt the upgrade process once it
has started, because there is a risk of irrepairable corruption. The upgrade may take several minutes to complete. If an upgrade does get
interrupted, try running the upgrade again.
Here's an example procedure to upgrade a database created with Berkeley DB 2.7.7 to use Berkeley DB 3.1.17:
1. Build and install the Berkeley DB 3.1.17;
2. Run configure in the INN source tree and make sure it picks up the right Berkeley DB directory (e.g., /usr/local/BerkeleyDB.3.1);
3. Do a "make";
4. Shut down INN (e.g., with "rc.news stop") and be sure to kill all instances of nnrpd as well;
5. Do a "make update" to install the new binaries;
6. Run "ovdb_init -u" as the news user;
7. Start INN with "rc.news".
It is OK to specify "-u" even if no upgrades are needed.
HISTORY
Written by Heath Kehoe <hakehoe@avalon.net> for InterNetNews.
$Id: ovdb_init.pod 7851 2008-05-26 19:33:08Z iulius $
SEE ALSO
ovdb(5), makehistory(8)
INN 2.5.3 2009-05-21 OVDB_INIT(8)