This bundles latest cmk release in cloudstack-management package, so
admins won't need to install it for typical first-install use.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
This changes deb and rpm packaging to build the UI using npm and bundle
it in the `cloudstack-management` package and a new `cloudstack-ui`
package. The `cloudstack-ui` package will install the UI under
`/usr/share/cloudstack-ui/`. For both packages the config.json will not
be overridden on upgrade and hosted at /etc/cloudstack/management
for the cloudstack-mangement package, and at /etc/cloudstack/ui for the
cloudstack-ui package. The cloudstack-ui package is for advanced users
who only want the UI want to setup reverse proxy (separate hosting of UI).
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Ubuntu 14.04 will go EOL in April 2019. With a new CloudStack
release close to that date we can drop support for this Ubuntu
version and the master branch of CloudStack.
Ubuntu 16.04 (Xenial) and 18.04 (Bionic) both have systemd and
more recent Java versions which make it easier to run the CloudStack
KVM Agent on them.
In addition libvirt and Qemu are more up to date with features
which allow VMs to run better.
Yet to be implemented features in KVM can also leverage the newer
version of Qemu and libvirt without the need of taking older
version of them into account.
Signed-off-by: Wido den Hollander <wido@widodh.nl>
- Migrate to embedded Jetty server.
- Improve ServerDaemon implementation.
- Introduce a new server.properties file for easier configuration.
- Have a single /etc/default/cloudstack-management to configure env.
- Reduce shaded jar file, removing unnecessary dependencies.
- Upgrade to Spring 5.x, upgrade several jar dependencies.
- Does not shade and include mysql-connector, used from classpath instead.
- Upgrade and use bountcastle as a separate un-shaded jar dependency.
- Remove tomcat related configuration and files.
- Have both embedded UI assets in uber jar and separate webapp directory.
- Refactor systemd and init scripts, cleanup packaging.
- Made cloudstack-setup-databases faster, using `urandom`.
- Remove unmaintained distro packagings.
- Moves creation and usage of server keystore in CA manager, this
deprecates the need to create/store cloud.jks in conf folder and
the db.cloud.keyStorePassphrase in db.properties file. This also
remove the need of the --keystore-passphrase in the
cloudstack-setup-encryption script.
- GZip contents dynamically in embedded Jetty
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
This feature allows root administrators to define new roles and associate API
permissions to them.
A limited form of role-based access control for the CloudStack management server
API is provided through a properties file, commands.properties, embedded in the
WAR distribution. Therefore, customizing API permissions requires unpacking the
distribution and modifying this file consistently on all servers. The old system
also does not permit the specification of additional roles.
FS:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+Role+Based+API+Access+Checker+for+CloudStack
DB-Backed Dynamic Role Based API Access Checker for CloudStack brings following
changes, features and use-cases:
- Moves the API access definitions from commands.properties to the mgmt server DB
- Allows defining custom roles (such as a read-only ROOT admin) beyond the
current set of four (4) roles
- All roles will resolve to one of the four known roles types (Admin, Resource
Admin, Domain Admin and User) which maintains this association by requiring
all new defined roles to specify a role type.
- Allows changes to roles and API permissions per role at runtime including additions or
removal of roles and/or modifications of permissions, without the need
of restarting management server(s)
Upgrade/installation notes:
- The feature will be enabled by default for new installations, existing
deployments will continue to use the older static role based api access checker
with an option to enable this feature
- During fresh installation or upgrade, the upgrade paths will add four default
roles based on the four default role types
- For ease of migration, at the time of upgrade commands.properties will be used
to add existing set of permissions to the default roles. cloud.account
will have a new role_id column which will be populated based on default roles
as well
Dynamic-roles migration tool: scripts/util/migrate-dynamicroles.py
- Allows admins to migrate to the dynamic role based checker at a future date
- Performs a harder one-way migrate and update
- Migrates rules from existing commands.properties file into db and deprecates it
- Enables an internal hidden switch to enable dynamic role based checker feature
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
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.
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.
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)
