aeolus security - round 2
by Mo Morsi
This patchset contains the remaining patches from the first set
rebased against the current head with the whitespace errors removed.
Additionally it incorporates more fixes from the list of tasks
from the controller audit, specifically:
* ensuring user has access to hwps retrieved
* verifying privileges on instances retrieved in an edge case
where it previously wasn't handled
* requiring access to config_server's provider account to test
the connection
* requiring Privilege::PRIV_VIEW to access roles
* require access to a realms provider when accessing realms
* correctly setting provider_account in provider_accounts_controller
destroy method (previously wasn't set but was never caught as we
currently using multi_destroy instead of destroy)
11 years, 10 months
[ANNOUNCE] Bundler usage change pushed to master
by Jason Guiditta
As anyone who works on aeolus knows, we have a few issues with
bundler, due to its completely opposite view of the world when
compared to any linux distribution (obviously rpm-based systems are
what many of us are on, but it applies more generally).
Upstream/standard ruby development (ie via 'bundle install') has been
largely broken for quite some time, as nobody has really been
developing that way, and our setup to this point has been pretty
painful to do it.
While this is not entirely solved, I just pushed a pair of patches
[1][2] that make the rpm-enviroment development setup simpler, as well
as putting in place most of what is needed to allow/simplify standard
ruby development practice. There are some remaining dependency issues
remaining to be sorted to get upstream fully functional, which I am
working on now (rack version between our version of rails and
rack-restful_submit, one of which has had its gemspec hacked in rpm
version to allow them to coexist). There is mre detail in the commit
messages, but I will outline here how this affects your life when
developing our application.
* You now only need to add your dependency to Gemfile.in and the rpm
spec. lockfile updates should be done in a ruby-only environment
(rvm or vm dedicated to such setup), as fedora dependencies will
likely never match upstream exactly
* No requires in application.rb
* Profit
Now, is you want to develop upstream (once deps are fixed), you can
either setup a machine for this, or just use rvm + a gemset, which
will always get you a clean environment in a pretty short amout of
time. For my setup, I just do:
$ rvm use 1.8.7-p357@conductor
$ export USE_BUNDLER=yes
Then just run everything as usual from source. Again, this will fail
for you _right_ now, but is only due to our broken deps, not bundler,
ruby, or any of the other things != us that people like to blame.
Feel free to reply here with any additional questions on this, or any
issues you may encounter.
-j
[1] Redmine #3318: Add small extension library to bundler to load
system gems
[2] Redmine #3319: Set up conductor to use new Bundler extension
point.
11 years, 10 months
[PATCH conductor 0/1] "" vs present?
by Matt Wagner
Howdy,
This is a trivial little patch based on something someone ran into today on IRC... If deltacloud_provider was an empty string (versus being nil), we were sending that through.
I used the surprisingly-uncommon present? method here. Because I was surprised to find that it's not widely used despite being something I find really useful (and because I have no life), I even wrote a quick blog post about it: http://ma.ttwagner.com/presence-in-rails/
-- Matt
11 years, 10 months
[PATCH 0/3] Bundler usage changes Rev 2
by Jason Guiditta
[PATCH conductor 1/3] Redmine #3241: Add small extension library to
[PATCH conductor 2/3] Redmine #3242: Set up conductor to use new
This last one is not meant to be pushed, and is simply here if you hit any issues
to help with debugging, feel free to not apply it unless you hit problems.
[PATCH conductor 3/3] WIP: add some logging to debug libraries that
This patchset implements Redmine feature #3162: 'As a developer, I would
like to be able to easily work using rubygem or rpm, and to be able to
swap back and forth, so that I can more easily test/develop against
different platforms'. Note that there seems to be a lingering issues with
what bundler see on an install where USE_BUNDLER=yes. In my testing, something
on the path was looking for rack ~> 1.2.1, but I cannot for the ife of me
figure out what. This does not keep the distro/rpm version from working, and I
believe it is a bug outside these patches' scope, so I just want to mention
that seems to be the only remaining blocker for upstream.
Testing of this set for standard rpm-only development is as usual:
* make sure you can run tests from src
* install rpm and verify things work
* make sure you can run a dev-mode server as expected
None of the above should show any calls to bunlder or 'bundle exec'. If they do,
there is a bug in these patches.
To test upstream, you need a clean env (perhaps via rvm and a gemset). You then set
the following env var:
* USE_BUNDLER=yes
Then run:
(you need to cp Gemfile.in -> Gemfile first for this step, and do this from src dir,
or specify full path)
* bundle install
This should install the the versions in our Gemfile.lock. Try to run tests:
* rake spec
This is where I hit the bad dep. Any assistance figuring out why is appreciated,
though I think I have made prgress tracking it down (and hope to have a patch to fix
the lockfile tomorrow).
-j
11 years, 10 months
[PATCH conductor] Add BuildRequires: systemd-units for daemons subpackage
by steve linabery
0cd0270d introduced a regression in that the %{_unitdir} macro
is not defined without this BuildRequires.
Note that this will break builds for RHEL, but rwsu is fixing.
This gets fedora builds working again.
---
aeolus-conductor.spec.in | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/aeolus-conductor.spec.in b/aeolus-conductor.spec.in
index b095c6b..59acab3 100644
--- a/aeolus-conductor.spec.in
+++ b/aeolus-conductor.spec.in
@@ -82,7 +82,7 @@ Requires(preun): initscripts
Requires(post): systemd-units
Requires(preun): systemd-units
Requires(postun): systemd-units
-
+BuildRequires: systemd-units
%description daemons
The configuration and daemons necessary to run and proxy the Aeolus Conductor.
--
1.7.6.5
11 years, 10 months
Cloudforms 1.1 testing repo
by Aziza Karol
Hi All,
Can anyone point me to the repo to be used for cloudforms 1.1 testing?
Thanks,
Aziza
11 years, 10 months
[PATCH conductor 2/2] Remove jquery-svg entries from rpm spec
by Imre Farkas
From: Imre Farkas <ifarkas(a)redhat.com>
---
aeolus-conductor.spec.in | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/aeolus-conductor.spec.in b/aeolus-conductor.spec.in
index 3f2ba30..b095c6b 100644
--- a/aeolus-conductor.spec.in
+++ b/aeolus-conductor.spec.in
@@ -176,8 +176,7 @@ getent passwd aeolus >/dev/null || \
# extension may exist. For instance cgi="public" means that src/public/*.cgi
# will be copied from the source into the RPM.
builder="app/views/errors"
-css="public/stylesheets public/stylesheets/jquery.ui-1.8.1 \
- public/javascripts/jquery-svg"
+css="public/stylesheets public/stylesheets/jquery.ui-1.8.1"
feature="features"
gif="public/images public/stylesheets/images"
haml="app/views/hardware_profiles app/views/realm_mappings \
@@ -201,7 +200,7 @@ mustache="app/views/instances app/views/pools app/views/deployments"
html="public"
ico="public"
jpg="public/images public/stylesheets/images"
-js="public/javascripts public/javascripts/jquery-svg \
+js="public/javascripts \
public/javascripts/jquery.ui-1.8.1 \
public/javascripts/jquery.ui-1.8.1/ui/minified \
public/javascripts/lib
@@ -218,7 +217,7 @@ rb="app/models app/controllers app/controllers/api app/helpers app/services app/
spec/factories spec/helpers spec/models spec/services spec/controllers/api lib/aeolus \
lib/aeolus/event"
rhtml="app/views/layouts"
-svg="public/images public/images/icons public/javascripts/jquery-svg public/fonts"
+svg="public/images public/images/icons public/fonts"
ttf="public/fonts"
eot="public/fonts"
woff="public/fonts"
--
1.7.6.5
11 years, 10 months
Adding new provider
by Nauman Thanvi
Hi All,
We tried to get the info on irc but especially the Image Factory developers
are difficult to approach due to opposite timezone.
I think people on irc already said there is no information on adding new
providers and the people doing OpenStack will try to write some.
We like to know specific files and parts for adding new provider and what
could be the start, I assume these are the steps
1- Adding support for DeltaCloud driver (its been done)
2- Adding provider type in conductor models [Need specific information on
files and procedure]
3- Adding config file FGCP
4- Image
- how we get a list of image id's from the FGCP and their descriptions
(CentOS 5.6 base OS, etc.)
- uploading an image is not supported so we can skip that part.
Is there any wiki to getting started for development mode? I've been trying
to play around with conductor and I must say it is painful, without having
much information
I'd like to know what cloud specific code needs to be written for Aeolus to
support for FGCP.
--
Thanks,
Nauman Tariq
11 years, 10 months