The qemu-kvm package has become deprecated in Ubuntu 14.04 and
the right package to install would be qemu-system-x86
To maintain backwards compatibility for older Ubuntu LTS releases
we depend on qemu-system-x86 or qemu-kvm
Since we've agreed to use JDK/JRE 1.7, this enforces that for Ubuntu builds
- this fix remove usage of 1.6 paths in JDK_DIR for cloud-{agent, management, usage}.
- adds oracle jdk 1.7 path (in case a user is using that)
- adds mysql-connector-java path to CLASSPATH for usage server
- adds libmysql-java pkg dependency (tested and available for precise and trusty)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
(cherry picked from commit 96d6a2a03734ebbb9f41196d56c409d544a268ea)
Conflicts:
packaging/debian/init/cloud-usage
Adds pessimistic logic to try the hard coded paths if Rajani's logic fails
We now require at least Java 7 to build and run CloudStack.
Both the DEB and RPM packaging now also require Java 7 during installation
of the packages.
Including following steps:
b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing bridge name to new bridge name, and update related firewall rules.
c. install a libvirt hook:
c1. mkdir /etc/libvirt/hooks
c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook /etc/libvirt/hooks/qemu
c3. chmod +x /etc/libvirt/hooks/qemu
c4. service libvirtd restart
(cherry picked from commit a0988780ad88bb56becb0a13efedcd79c1bee142)
Signed-off-by: Wei Zhou <w.zhou@leaseweb.com>
(1) Replacing db.properties with management server db.properties
(2) Rename log4j-cloud_usage.xml to log4j-cloud.xml
(cherry picked from commit fb97e8e617393ac86924304f2765e933cfa30a6a)
This are symlinks to server-nonssl.xml and tomcat6-nonssl.conf, but
they are required for starting the management server.
Commit 2db7a4559e64e34b5c707157db240a1be322cb69 broke this.
We should be carefull what we package since all configuration should
be in /etc/cloudstack/management
Signed-off-by: Wido den Hollander <wido@widodh.nl>
working again.
The newly created package for cloudstack-management was not correctly
installing the service. This prevented cloud-setup-management from being
able to configure the service, and the init script didn't even believe
the service was installed. I also added sudo to the chmod command for
checking script permissions, as most scripts belong to root. It was
trying to configure the agent with cloudstack-setup-agent but the script
was still called cloud-setup-agent, so I renamed it to cloudstack-setup-agent.
The old packages used to write this data to the configuration
in a postinst file.
That was horrible to track since system administrators had no
idea what was going on.
We no longer symlink db.properties to the management server, but
we create a own db.properties for the usage server.
During a upgrade we copy the file to make the upgrade easier.
