We are trying to install Orion Context broker using the guide from FIWARE (https://fiware-orion.readthedocs.io/en/master/admin/yum/index.html), but when executing the yum command it returns a 404 error. There is another thread with the same error (2020) but still not solve. The problem is not the cache. This the exact error:
Error:
Problem: cannot install the best candidate for the job
nothing provides /usr/bin/python needed by contextBroker-2.2.0-1.x86_64
nothing provides libboost_filesystem-mt.so.1.53.0()(64bit) needed by contextBroker-2.2.0-1.x86_64
nothing provides libboost_regex-mt.so.1.53.0()(64bit) needed by contextBroker-2.2.0-1.x86_64
nothing provides libboost_system-mt.so.1.53.0()(64bit) needed by contextBroker-2.2.0-1.x86_64
nothing provides libboost_thread-mt.so.1.53.0()(64bit) needed by contextBroker-2.2.0-1.x86_64
nothing provides libgcrypt.so.11()(64bit) needed by contextBroker-2.2.0-1.x86_64
nothing provides libgcrypt.so.11(GCRYPT_1.2)(64bit) needed by contextBroker-2.2.0-1.x86_64
nothing provides libgnutls.so.28()(64bit) needed by contextBroker-2.2.0-1.x86_64
nothing provides libgnutls.so.28(GNUTLS_1_4)(64bit) needed by contextBroker-2.2.0-1.x86_64
nothing provides libgnutls.so.28(GNUTLS_3_0_0)(64bit) needed by contextBroker-2.2.0-1.x86_64
nothing provides libgnutls.so.28(GNUTLS_3_1_0)(64bit) needed by contextBroker-2.2.0-1.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
Any help is more than welcome.
It seems to be somekind of mismatch between the packages your are trying to install with yum and the packages available in the yum repository configured in your operating system. However, given you haven't provided information about your CentOS operating system version, I cannot provide further help.
However, I see you are trying to install Orion 2.2.0. Note that is a very old version (released in Februrary 2010, almost three years ago!). I'd recommend you to install Orion 3.4.0 (latest version released at the moment of writing this) which uses CentOS 8 as official operating system.
Related
I have installed Motioneyeos on a Pi Zero and on a Pi2, and it works like a charm in both of them. The control of the 2 systems can be unified on the web server of any one of them. The web interface is clear and allows to customize hundreds aspects of the program. Anything perfect so far.
Trying to understand a little bit how does it work, I have logged to one of the 2 Pis through ssh and I have checked that the OS is kept to a bare minimum. uname -r returns 4.19.65.
On the web interface of the app it is possible to check if the last version of the program is the one running. I have checked, and yes, I have the last version.
My question is: does it make sense to upgrade the OS components used by the program (apt update, apt dist-upgrade) even if the last version of the program is the one running in my Pis? Apt is not even installed, so the first thing would be to bring it there and install it, but I am afraid that if I update the OS, the program may stop to work...
I answer myself thanks to the feedback received in another forum. Motioneyeos is an embedded software based on Buildroot and as such it is not possible to install any package on it. To be able to install a package on Motioneyeos, Motioneyeos has to be installed on an full OS as Raspbian following the instructions in Motioneyeos web ==>>
I am installing OpenProject 8.3.1 on my apache 2.4 CentOS7 WHM/CPanel VPS using packaged installation and I've run into the following problem:
When I run openproject configure right after installation process it goes well up until the line "No package mod_ssl available". Followed by "Error: Nothing to do". Openproject can't be accessed.
I'm using PostgreSQL and auto installation/configuration option. I've tried skipping all but the most essential options in configuration, to no help.
The mod_ssl unavailable bit is the most surprising, since after I run rpm -qa|grep mod_ssl I get "ea-apache24-mod_ssl-2.4.38-3.3.1.cpanel.x86_64" - meaning I in fact do have mod_ssl available.
It looks like you are using a non-standard CentOS edition with CPanel. I don't think OpenProject can be installed on such a distribution, because it seems to come with limitations as to what packages are available. The mod_ssl package you mention is the one originally distributed by the CentOS distribution.
In my deep dive into the CentOS terminal, I was able to install and setup Jira, Confluence, and Bitbucket servers. However, the Hipchat Server seems to be based on something completely different.
Is there a step by step guide to installing Hipchat; From what's needed (dependencies) to installing (which I'm not even sure is part of the process) to seeing it work (log-in, etc.)?
Atlassian's official guide is written in such a way, that I look at it confused - as if it's a riddle that will never be solved. lol
By HipChat4, I'm assuming you refer to the HipChat Client. If so, have you tried the instructions outlined here?
sudo bash -c ‘cat > /etc/yum.repos.d/hipchat.repo << EOF_hipchat
[atlassian-hipchat]
name=Atlassian Hipchat
baseurl=https://atlassian.artifactoryonline.com/atlassian/hipchat-yum-client/
enabled=1
gpgcheck=0
EOF_hipchat’
sudo yum update
sudo yum install hipchat4
If what you're trying to install is the server, then keep in mind that HipChat Server is only supported on AWS (via the Atlassian provided AMI), or as a VM for private datacenters (via the Atlassian provided OVA). You can't install HipChat Server directly on a Linux box.
If your OS can run a virtualization platform (e.g. VirtualBox) then you can download the OVA from https://www.hipchat.com/server#get-hipchat-server, import it, start your VM and configure it. More thorough instructions are available here.
I am running a web server based on CentOS 5.8 and I need to upgrade my version of bind to make it PCI compliant. I'm currently running bind 9.3.6 and I need to have bind 9.9.8 or higher. I've tried yum update bind but apparently I already have the latest version according to yum. I did some Googling and I found an RPM file bind-9.10.2-1.el5.i686.rpm which looks like it would work but i don't know if it should try installing it or not. I think I would need bind-devel and bind-libs which I can get from the same site. Am I better off compiling from source? I know CentOS 5 is old but I'm trying to avoid reinstalling the whole server.
Installing binary rpm's from later versions of CentOS is unlikely to work: there are many changes since CentOS5.
Rebuilding a src.rpm locally is one way to see what issues there are.
Meanwhile, upgrading to CentOS6 (at least: CentOS7 uses systemd which takes some study) is often not a whole lot more effort than retrofitting something like bind, and will have other efficiencies. YMMV, everyone's does.
My collegue and I develop a small Python application. We use Vagrant to set up development environments.
Suppose my collegue introduces a new feature into the application. Feature's implementation requires a new python dependency (3rd party package) and the dependency itself needs some system libraries. If I do not read through all pulled commits carefully I can miss, that some systems libraries have to be installed prior running the project.
Of course we update Vagrantfile to install such non-python dependencies during provisioning, so if someone clones project's repository and issues vagrant up he will get a fully working development environment, but what shoud I do to automate updates in my existing environment?
How should we indicate, that a new dependency (python or non-python) was added and we need to install it by firing a specific command?
UPD I can try and run the application and if I encounter any errors it is a sign to reprovision my vagrant box, but it seems tedious to me to test a feature by hands and run provisioning scripts later
I ran into this with Ruby as well. We used Bundler, which is a dependency management system for Ruby. If I pulled in new code, ran it and got funky exceptions saying that a certain dependency was missing, I just knew it was time for a bundle install from the command line. The solution to your problem is the same. If you run the code and get errors saying a dependency is missing, your default response to that exception should be to vagrant up on the command line, and try again.
Barring that, sending an email to your teammates with instructions about the new or updated dependency is a good way to go, especially if a vagrant up is insufficient to resolve the missing or incorrect dependency.