I have installed Icinga version Icinga Classic UI 1.11.5 (Backend 1.11.5) - But I want to install Icinga 2 on my CentOS 6.
Can you please let me know which file do I want to take backup so that my previous Icinga version will not be overwritten? Or how could I upgrade my current Icinga version to Icinga 2?
Please provide the steps to install Icinga 2 on my CentOS 6?
You don't have to backup your old icinga folder since icinga2 will be installed in /etc/icinga2, e.g. a new directory.
The icinga2 configuration files differ from icinga(1) though, so you have to recreate them using the icinga2 syntax.
Upgrading Icinga 2 is usually quite straightforward. Ordinarily the only manual steps involved are scheme updates for the IDO database. 1) Upgrade the mysql database 2) OR if postgre just upgrade the postgre database .If you are migrating from ICINGA1 to ICINGA2 then its better you follow the documentation as it describes the migration plan throughout.
For Icinga2 and icinga-web installation
http://karanreddys.blogspot.in/2015/07/icinga2-and-icinga-web-installation-on.html
Related
Since Bitnami stopped Centos installer and started to support only ova, we are stuck with old version, Looking for document which talks about migrating Bitnami Gitlab to Latest Gitlab CE omnibus. We use external dbs.
In this link you can find the process a user followed to upgrade Gitlab from non-omnibus to omnibus: https://community.bitnami.com/t/migration-of-data-and-upgrading-from-bitnami-gitlab-7-10-1-to-latest-gitlab-enterprise-version/46741/12?u=jsalmeron
From the GitLab backup/restore docs:
You can only restore a backup to exactly the same version and type (CE/EE) of GitLab on which it was created. The best way to migrate your repositories from one server to another is through backup restore.
Here's what I would do:
Create a full backup of the old GitLab instance using the rake task
Install a new instance of GitLab 8.9.6 in your new server (using Omnibus distro package)
Restore the backup to your new server
Slowly upgrade your new server to the latest version
I would only skip about 2-4 minor versions at a time, and recommend going back through and reading the release notes of each version.
E.g. yum install gitlab-ce-9.1.0
At present we are on Apache/2.2.15 (UNIX) version. To fix the vulnerabilities we are suggested to upgrade to new version. I got new version from online using "wget" command and followed steps mentioned on this link http://httpd.apache.org/docs/2.2/install.html#download.
Once I am done, checked version using httpd -v. It gives me old version Apache/2.2.15 (UNIX). If I check using /usr/local/apache2/bin/httpd - v. It gives me new version. Did I successfully upgraded the version or not? If not what should I do?
I tried "yum install httpd" - It says "Nothing to do".
You now have two versions of Apache installed. You have the one installed with the system package manager (yum) in /usr/sbin/httpd. You have one installed manually in /usr/local/apache2/....
Which one you get will be determined entirely by which path you use.
In general, mixing system-managed packages with manually installed packages is a recipe for trouble. If you want to stick with the newer version in /usr/local, you should remove the system version, and realize that you will lose some manageability. For example, you will no longer be able to use yum install ... to install new Apache modules, and you will not be able to verify the installed files using tools like rpmverify.
If your distribution currently has Apache 2.2.x, that suggests your distribution is fairly old. For example, RHEL (and CentOS) 7 (and similar variants) have version 2.4.6 packaged, so you may want to update your host to something newer than whatever you're running now.
Yes, its successfully upgraded as per the screenshot.
httpd 2.2.15 is the version with RHEL 6 repository, here HTTPD_HOME is /etc/httpd (Highest version provided for HTTPD via RPM RHEL 6 is 2.2.15)
httpd 2.4.6 is the version with EPEL-HTTPD24 repository, here HTTPD_HOME is /usr/local/apache2/
I recently updated Postgres from version 9.3 to 9.6. After the update all of my commands (such as pg_dumpall) all point to version 9.3. I get the error of version mismatch.
I found that if I change my symlink in /usr/bin to point to 9.6 it seems to work. Is there a better way to point my commands to version 9.6? Thanks you for your help!
The best way to do it is using the package manager of your linux distro: it ensures all symlinks are changed to the newer version.
From your question it is possible to infer that the upgrade was done without using the package manager. I suggest to try to install Postgres with the package manager or give a little more information about your system so we can give you a more accurate answer.
I am using cassandra 2.0.5 on Centos 6.5 and OpsCenter 4 worked fine until i updated OpsCenter to version 4.1 . I access OpsCenter page, click on manage existing cluster and give the ip address of my node (127.0.0.1) and it gives me the following: "Error creating cluster: max() arg is an empty sequence".
Any clues ?
The bug is on 4.1.0, and is affecting those running Python 2.6. The complete fix for this is 4.1.1 (http://www.datastax.com/dev/blog/opscenter-4-1-1-now-available). To workaround this issue on 4.1.0, users should disable the auto-update feature, and manually re-populate the latest definitions. This will only need to be done once. This doesn't need to be done with 4.1.1, and that's the best fix. See the Known issues of the release notes (http://www.datastax.com/documentation/opscenter/4.1/opsc/release_notes/opscReleaseNotes410.html)
Add the following to opscenterd.conf to disable auto-update:
[definitions]
auto_update = False
Manually download the definition files
for tarball installs:
cd ./conf/definitions
for packages installs:
cd /etc/opscenter/definitions
Apply the latest definitions
curl https://opscenter.datastax.com/definitions/4.1.0/definition_files.tgz | tar xz
Restart opscenterd
I jus had today the same problem that you. I downloaded an older versions of opscenter (particulary version 4.0.2) from http://rpm.datastax.com/community/noarch/ and the error has gone.
I am also using the sam cassandra version and also on centos
I have a server currently running RHEL 5.1, and I would like to upgrade it to RHEL 5.4. The server is not connected to the Internet, so I don't think I can use "yum update".
How would I be able to upgrade my server, and is it just a small-scale upgrade, like Windows patches, leaving everything on the server intact, or would it delete everything that was on the server?
Thank you.
Regards,
Rayne
I haven't actually tried this myself, but you should be able to use an installation disc for RHEL 5.4 to upgrade even if you are off-line (although you'll need to get on-line somewhere to download the disk image). Once you have the RHEL 5.4 disc, you should be able to follow the instructions here:
How do I use yum to update or install packages for Red Hat Enterprise Linux 5 from a customized repository?
to update your system. Basically, you create a custom repository on you hard drive with the rpm files from the disk and point yum at it or use the disc directly.
Good luck.
Of course if you can put the server temporarily on-line and just use the on-line repositories, after updating all the packages in your 5.1 distribution, you'll have all the same files as if you installed 5.4. At least that's what I remember happening. I had a 5.0 installation that I kept updated and when I compared them they seemed to be the same as the 5.3 version (current at the time) although during boot, my system said it was still 5.0
Rayne,
I used to work on DOE classified systems that could never touch the public internet. There is a very easy way to do this as mentioned. Just use the ISO as a repo, and for my example to work, it needs to be a DVD image. (The way around that using disk {1,2,3} is to copy the files from each disk onto the local disk or a storage device)
You will need to install createrepo which for me involved two dependencies.
createrepo
deltarpm
python-deltarpm
mkdir -p /mnt/iso/rhel54
mount -o loop /path/to/rhel5.4.iso /mnt/iso/rhel54
cd /mnt/iso
createrepo .
It will look like this:
[root#hostname iso]# createrepo .
44/20586 - rhel54/HighAvailability/Packages/PyQt4-4.6.2-8.el6.x86_64.rpm
Create /etc/yum.repos.d/rayne.repo and add
[Rayne-repo]
baseurl=file:///mnt/iso/
enabled=1
gpgcheck=0
Then run yum update
The update from RHEL 5.1 to RHEL 5.4 is not a small one, not like Windows patches. You can read the release notes, but you will end up with a newer kernel in the end and a ton of updates to the packages. I have not upgraded from 5.X to 5.Y+3 before, it's always been incremental (5.1 to 5.2). At any rate, this should work for you.