Normal users would require /sbin in their paths to access lsmod, this adds
a profile.d script that adds /sbin, for centos7, f20 and f21 packages.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
This allows non-root users to add KVM hosts, the user should be an admin or
added to sudoers to execute sudo cloudstack-setup-agent.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Signed-off-by: Remi Bergsma <apache@remi.nl>
This closes#288
(cherry picked from commit d2b0c1a32b)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
- Removes awsapi packaging rules for debian, centos63, centos7, fedora 20/21
- Removes catalina port 7080 service configs
- Fixes build replace properties for AWSAPILOG
- Removes maven profile for building awsapi and deploying db in developer profile
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Following actions from discussions on dev ML regarding removing awsapi and
prefering ec2stack. Reference from last PR:
https://github.com/apache/cloudstack/pull/44
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
CLOUDSTACK-7460: mgmt server package should not create agent directory
Revert "CLOUDSTACK-8402: Depend on openjdk 1.7 for both CentOS 6 and 7"
Revert "CLOUDSTACK-8404: uninstall/conflict if java-1.8.0-openjdk is installed"
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
This would force to uninstall openjdk 1.8.0 and only install 1.7 in case of ACS
4.5.x releases. On master/4.6, we might support java 1.8.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
This commit forces rpms to depend on java-1.7.0-openjdk which is available
on both CentOS 6 and CentOS 7, also the version that ACS 4.5 supports.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Depend on java-1.7.0-openjdk for EL7 rpms as agent fails with openjdk8. This
fix needs to be reverted/removed to use openjdk8 once we start supporting it.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
rpmbuild complained about the date "Fri Oct 03 2012"
according to the calendar, Oct 3 2012 was Wednesday
Signed-off-by: Laszlo Hornyak <laszlo.hornyak@gmail.com>
The initial commit (f96c65416a) missed part of the change to package.sh, so we were not actually passing through the simulator build option to the rpmbuild call. This patch completes the support.
(cherry picked from commit e717450e0e)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
The -Xms value specifies the minimum heap size the JVM should start with and
-Xmx is the maximum heap size it can grow. The previous fix imposed minimum
limit of 1G which is unreasonably for small deployments. The fix is to start
with 256MB and limit to 2G for cloudstack-agent process. This was tested on
DevCloud/KVM and then again on a ACS/KVM deployment on real hardware.
With these values, it's possible for the agent to work in a DevCloud/KVM
environment and if JVM needs it can increase the heap size to 2G. The fix also
ports these settings to Debian cloud-agent init.d script as well.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
(cherry picked from commit bb81082e58)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
The -Xms value specifies the minimum heap size the JVM should start with and
-Xmx is the maximum heap size it can grow. The previous fix imposed minimum
limit of 1G which is unreasonably for small deployments. The fix is to start
with 256MB and limit to 2G for cloudstack-agent process. This was tested on
DevCloud/KVM and then again on a ACS/KVM deployment on real hardware.
With these values, it's possible for the agent to work in a DevCloud/KVM
environment and if JVM needs it can increase the heap size to 2G. The fix also
ports these settings to Debian cloud-agent init.d script as well.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
(cherry picked from commit bb81082e58)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
The initial commit (f96c65416a) missed part of the change to package.sh, so we were not actually passing through the simulator build option to the rpmbuild call. This patch completes the support.
In init.d scripts, the LSB header may specify what kind of service is
provided by an init script. If spaces are used, this means the init
script is providing several boot facilities. We fix that by using an
hyphen.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
(cherry picked from commit 2401eb927b)
In init.d scripts, the LSB header may specify what kind of service is
provided by an init script. If spaces are used, this means the init
script is providing several boot facilities. We fix that by using an
hyphen.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
changed the order of preference to check for java first.
Usage server rpm installs JRE 1.7. In the case where JDK 1.6 is already
installed, java version would be 1.7 but, javac would be 1.6
If javac is given preference, usage server fails to start in this case.
On a secured environment (selinux w/ env_reset enabled in sudoers), the
runuser command that is invoked by the daemon() function does not pass
along environment variables, so $JAVA_HOME is empty, and JSVC falls
back to its default behavior, which may not find java or may not find
the intended java.
This fix simply passes $JAVA_HOME explicitly using the -home argument to
JSVC.
Signed-off-by: Rajani Karuturi <rajanikaruturi@gmail.com>
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 96d6a2a037)
Conflicts:
packaging/debian/init/cloud-usage
Adds pessimistic logic to try the hard coded paths if Rajani's logic fails
Replacing whatami with $0 which is how UNIX shell scripts should get the
script's name.
BUG-ID: CLOUDSTACK-6129
Bugfix-for:
Reviewed-by:
Reported-by:
Signed-off-by: John Kinsella <jlk@stratosec.co> 1392660036 -0800
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.
All of the code changes for the Spring Modularization will work in
a modularized context or a non-modularized context. This commit
is the final commit to turn modularization on. Revert this commit
to disable the modularization and go back to monolithic Spring
configuration.
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 a0988780ad)
Signed-off-by: Wei Zhou <w.zhou@leaseweb.com>
[upgrade][2.2.13 -> 2.2.14 -> 4.2][KVM] When we try to upgrade the KVM agent from 2.2.14 to 4.2 using the "U" option in install.sh script, management server also gets installed!
[upgrade][2.2.13 -> 2.2.14 -> 4.2][KVM] When we try to upgrade the KVM agent from 2.2.14 to 4.2 using the "U" option in install.sh script, management server also gets installed!
Retains the systevm.iso from the previous run causing systemvm.iso to
never update itself. Do a complete clean install for all profiles
specified in mvn.
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
Added ipset in cloud.spec as part of agent install.
Signed-off-by: Pradeep <pradeep.soundararajan@citrix.com>
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
Detail: Uninstallation of old RPMs wipes out some of the configs, and makes it
difficult to reapply existing configs. This change moves the config directory
to cloud.rpmsave, and then pulls in necessary files from that location during
post install of agent and management server.
Test passed:
install 4.0 RPMs, set up advanced zone
build 4.1 RPMs via package.sh, with this patch
install 4.1 RPMs
restart cloudstack-management, cloudstack-agent
verify management, agent, and zone is operational
BUG-ID: CLOUDSTACK-1694
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1364409632 -0600
Summary: EC2 REST API: AWS APIs are not getting translated on the CloudStack Management Server and AWS API Installation Problems.
Fixing the class not found exception, key not found and other issues as mentioned in the above two defects.
Signed-off-by: Pradeep <pradeep.soundararajan@citrix.com>
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.
Summary: EC2 REST API: AWS APIs are not getting translated on the CloudStack Management Server and AWS API Installation Problems.
This fixes the above two defects and other packaging related issues.
Signed-off-by: Pradeep <pradeep.soundararajan@citrix.com>
Proposing to modify package.sh script. Package as per OSS or NONOSS arguments.
Now package.sh will act based on the below usage i.e. with or without
arguments:
./package.sh -h
usage: ./package.sh [-p|--pack] [-h|--help] [ARGS]
oss|OSS To package OSS specific
nonoss|NONOSS To package NONOSS specific
Examples: ./package.sh -p|--pack oss|OSS
./package.sh -p|--pack nonoss|NONOSS
./package.sh (Default OSS)
Signed-off-by: Pradeep <pradeep.soundararajan@citrix.com>
Moved the post awsapi section to the post management since it is trying to provide symb link before installing management server.
Signed-off-by: Pradeep <pradeep.soundararajan@citrix.com>
server. It was printing a meaningless failure if the cloud
user's home dir didn't need to be updated.
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1362809648 -0700
Detail: This gets rid of the patchdisk method of passing cmdline and
authorized_keys to KVM system VMs. It instead passes them to a virtio socket,
which the KVM guest reads from the character device /dev/vport0p1 during
cloud-early-config. Tested to work on CentOS 6.3 and Ubuntu 12.04. Should
work with even older versions of libvirt.
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1362691685 -0700
For both the RPM and DEB packages are new directory for plugins
for the agent is created.
All JAR files in that directory will be added to the classpath
on boot of the agent.
The RPM init script was lacking some things, it is synced
now with the DEB init script.
Both prefer Java 7 over Java 6 and add the correct JAR files to the
classpath.
Libvirt-java 0.4.9 works just fine with JNA 3.2.4 which is in
all distributions.
Future libvirt version require at least JNA 3.5.1 due to new methods
and memory management, but that is not our concern now.
By depending on the JNA in the distribution and adding it to the classpath
we can work just fine.
The new cloudstack-agent package wouldn't boot due to various issues.
Those all seem to be resolved.
Other changes include path changes like /etc/cloud -> /etc/cloudstack
The new package now installs, but the upgrade hasn't been tested yet.
web.xml now references a log4j-cloud.xml relative to the webapp root
to capture early logging from spring. This change introduces a symlink
in the client webapp to the system wide log4j-cloud.xml which works around
a problem starting cloud-management described in CLOUDSTACK-1436
CLOUDSTACK-1436: 4.1 management server fails to start from RPM...
CLOUDSTACK-1423: Unable to launch UI [HTTP Status 404 - ]
Signed-off-by: David Nalley <david@gnsa.us>
Detail: getting "hard link not allowed for directory" due to line 321 in
cloud.spec. Changing to symlink.
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1361982798 -0700
Some concepts included:
* the replace.properties location used by maven is parameterized to allow
for a build that does not modify the currently git tracked files
* package naming is updated along the lines of what was discussed on the
-dev mailing list and between committers at the Build a Cloud Day in Belgi
* package version pattern is updated (since we redo all package names,
we might as well drop the epoch)
Change on cloud.spec for the message about vhd-utils point to the new
location of cloudstack scripts
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
Description: current package.sh fails if user hasn't downloaded all maven poms
prior to running package.sh. Now we match for something that vaguely resembles
a cloudstack version.
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1360889840 -0700
The change in package script allowed us to create proper tar under rpmbuild/SOURCES directory
The change in the path enabled us to launch the management server properly.
Signed-off-by: Hugo Trippaers <htrippaers@schubergphilis.com>
Committed-by: Hugo Trippaers <htrippaers@schubergphilis.com>
Remove duplicate entries in the config dir
Fix directory permisisons of some directories
Remove the scripts from the webapp as they are packaged inside the cloudstack-common package
Make the start method work again with jsvc
Move the usageApplicationContext to resources and add resources to the pom.xml
Remove the old components file
Add mysql-connector as a runtime dependency
Rename the usage package and the files to cloudstack
Change paths to the new proposed locations
Modify the spec file to package the agent files and the scripts
Some changes to the poms to put the java dependencies in the right place.
Move the agent script to the dedicated os dir in packaging.
Right now it isn't working yet, but this is the way it should start working
like the RPM package building is.
This commit is to clean up the rules file a bit and lay the groundwork for
the Debian packaging
This is a manual merge of the maven-to-rpm branch. This commits show how an RPM
package can be built without waf. The current version only builds the management
server rpm and some related rpms like setup. The main missing items are agent rpm and
the awsapi rpm. But it should at least show how to use maven and packaging.
Several small tweaks are put into the client/pom.xml to make sure that the war
has all items required to run as a standalone war.