[PATCH configure] BZ #850571 - remove permissive postgres hba config, use postgres system user instead
by Mo Morsi
---
recipes/aeolus/files/pg_hba-ssl.conf | 7 -------
recipes/aeolus/files/pg_hba.conf | 4 ----
recipes/aeolus/manifests/conductor.pp | 15 +--------------
recipes/postgres/manifests/user.pp | 12 ++++++------
4 files changed, 7 insertions(+), 31 deletions(-)
delete mode 100644 recipes/aeolus/files/pg_hba-ssl.conf
delete mode 100644 recipes/aeolus/files/pg_hba.conf
diff --git a/recipes/aeolus/files/pg_hba-ssl.conf b/recipes/aeolus/files/pg_hba-ssl.conf
deleted file mode 100644
index 722867b..0000000
--- a/recipes/aeolus/files/pg_hba-ssl.conf
+++ /dev/null
@@ -1,7 +0,0 @@
-# we are still leaving Unix-domain sockets open, if we want to disable
-# make sure to append "sslmode=require" and "-h localhost" to all psql
-# commands
-local all all trust
-hostssl all all 127.0.0.1/32 md5
-hostssl all all ::1/128 md5
-
diff --git a/recipes/aeolus/files/pg_hba.conf b/recipes/aeolus/files/pg_hba.conf
deleted file mode 100644
index ef3f6f5..0000000
--- a/recipes/aeolus/files/pg_hba.conf
+++ /dev/null
@@ -1,4 +0,0 @@
-local all all trust
-host all all 127.0.0.1 255.255.255.255 md5
-host all all ::1/128 md5
-
diff --git a/recipes/aeolus/manifests/conductor.pp b/recipes/aeolus/manifests/conductor.pp
index 30882c3..00c80e4 100644
--- a/recipes/aeolus/manifests/conductor.pp
+++ b/recipes/aeolus/manifests/conductor.pp
@@ -96,30 +96,17 @@ class aeolus::conductor inherits aeolus {
owner => 'postgres',
group => 'postgres',
notify => Service['postgresql'] }
- file { "/var/lib/pgsql/data/pg_hba.conf":
- source => "puppet:///modules/aeolus/pg_hba-ssl.conf",
- require => Exec["pginitdb"],
- owner => 'postgres',
- group => 'postgres',
- notify => Service['postgresql']}
file { "/var/lib/pgsql/data/postgresql.conf":
source => "puppet:///modules/aeolus/postgresql.conf",
require => Exec["pginitdb"],
owner => 'postgres',
group => 'postgres',
notify => Service['postgresql']}
- } else {
- file { "/var/lib/pgsql/data/pg_hba.conf":
- source => "puppet:///modules/aeolus/pg_hba.conf",
- require => Exec["pginitdb"],
- owner => 'postgres',
- group => 'postgres',
- notify => Service['postgresql']}
}
postgres::user{"aeolus":
password => "v23zj59an",
roles => "CREATEDB",
- require => [Service["postgresql"], File["/var/lib/pgsql/data/pg_hba.conf"]] }
+ require => Service["postgresql"] }
# Create aeolus database
diff --git a/recipes/postgres/manifests/user.pp b/recipes/postgres/manifests/user.pp
index a910a2e..e767e1d 100644
--- a/recipes/postgres/manifests/user.pp
+++ b/recipes/postgres/manifests/user.pp
@@ -2,13 +2,13 @@ define postgres::user($ensure='created', $password="", $roles=""){
case $ensure {
'created': {
exec{"create_${name}_postgres_user":
- unless => "/usr/bin/test `psql postgres postgres -P tuples_only -c \"select count(*) from pg_user where usename='${name}';\"` = \"1\"",
- command => "/usr/bin/psql postgres postgres -c \
- \"CREATE USER ${name} WITH PASSWORD '${password}' ${roles}\""}}
+ unless => "/usr/bin/test `/usr/bin/su postgres -c \"psql postgres postgres -P tuples_only -c \\\"select count(*) from pg_user where usename='${name}';\\\"\"` = \"1\"",
+ command => "/usr/bin/su postgres -c \"/usr/bin/psql postgres postgres -c \
+ \\\"CREATE USER ${name} WITH PASSWORD '${password}' ${roles}\\\"\""}}
'dropped': {
exec{"drop_${name}_postgres_user":
- onlyif => "/usr/bin/test `psql postgres postgres -P tuples_only -c \"select count(*) from pg_user where usename='${name}';\"` = \"1\"",
- command => "/usr/bin/psql postgres postgres -c \
- \"DROP USER ${name}\""}}
+ onlyif => "/usr/bin/test `/usr/bin/su postgres -c \"psql postgres postgres -P tuples_only -c \\\"select count(*) from pg_user where usename='${name}';\\\"\"` = \"1\"",
+ command => "/usr/bin/su postgres -c \"/usr/bin/psql postgres postgres -c \
+ \\\"DROP USER ${name}\\\"\""}}
}
}
--
1.7.10.2
11 years, 8 months
Fedora 17 & Aeolus Problems
by Nitesh Narayan
Hi,
Few days back I switched to Fedora 17 so I installed aeolus but when I tried to run it after configuring the iptables files and other things through "https://localhost/conductor" then I got a 404 Not Found message . I tried to restart the services and tried agagin but still there was no sucess .
Are there any issues present in Aeolus with Fedora 17 ?
Print only if its necessary
Regards
Nitesh Narayan Lal
11 years, 8 months
Aeolus jekyll website?
by Justin Clift
Hi Francesco,
Is this the right source location for the new jekyll
based website?
https://github.com/aeolus-incubator/aeolus-incubator.github.com
If so, the README needs to include steps for building
the site after cloning the repo. i.e.:
$ some jekyll commands ?
Imagine a new user (ie me) knows how to clone stuff,
but has no idea what steps are next to actually
make the site, before attempting any changes themselves.
You ok to update it?
Regards and best wishes,
Justin Clift
--
Aeolus Community Manager
http://www.aeolusproject.org
11 years, 8 months
[PATCH 0/2 conductor] minor efficiency fixes to the Monitor page
by Tzu-Mainn Chen
This patch addresses some issues brought up by BZ 848090 regarding efficiency. The BZ has since been closed, as the extreme load could not be replicated; however, I found the following issues while investigating, and they seem worth implementing:
a) removed some unneeded user statistics
b) removed eager loading of deployments and instances, after verifying that they were only needed for counts
Mainn
11 years, 8 months
Deployable and System Template Portability
by James Labocki
Sorry for posting across both lists, but this involves both aeolus and katello.
Last week a few of us were discussing the ability to import/export deployables within aeolus for sharing between differing implementations.
The attached photo 1.JPG provides a high level diagram of some of the problems we believe exist in achieving this today. Please note that I used enterprise nomenclature, so I think that:
- System Engine = Katello
- Component Outline = Assembly
- Blueprint = Deployable
- AppForm = Deployment
We found the following areas differ between implementations and would need to be accounted for. Note this this was not an exhaustive exercise and I'm sure we missed some areas.
- Providers paths are different in katello
- Certificates are different in system templates
- Repositories are different in system templates
- Deployables and their services are tightly coupled (not shareable)
- Clouds, Cloud Resource Zones, and Catalogs are different in aeolus
There seem to be a few approaches that we can use.
#1 Create an import/export tool that prompts users for various implementation specific areas (repository names, certificate locations, etc).
#2 Use the work Francesco has been doing on templates.aeolusproject.org to solve the problem by having it integrated into aeolus and contain the logic that would abstract environment differences from end users.
#3 Allow users to import/export the corresponding images along with the blueprint (this does not help with ongoing management through katello).
#4 Change the template/image/assembly/deployment model to allow for users to easily create an application blueprint from someone elses environment.
#5 Create some consistency in implementation (share system templates via ACME_Corporation org in katello for example).
I'm curious as to what approaches are being considered in both aeolus and katello to allow for users to share their system templates and deployables with minimal effort.
11 years, 8 months
Aeolus-image + upstream OAuth gem
by Jiří Stránský
Hi,
I'm trying to solve the upstream OAuth problem and I could use some opinions from people familiar with Aeolus-Image and OAuth.
There was a change in behavior in OAuth gem v0.4.6. I'm not entirely convinced whether the change should be considered a bug or a feature and whether the change is going to persist or be reverted later. (BTW Rawhide stays away from 0.4.6 as well and continues to ship 0.4.4 [1].)
Problem description:
--------------------
Our code interacting with OAuth is in this code block [2].
Our code generates resource paths including the site prefix, like
`/imagefactory/builders`
(The prefix would be present even if we used default ARes behavior and didn't override the path generation methods.)
The OAuth site for imagefactory is set in settings.yml to this:
`https://localhost:8075/imagefactory`
*OAuth 0.4.4 treats the resource path as full path* on the host and generates HTTP request to URL:
`https://localhost:8075/imagefactory/builders`
*OAuth 0.4.6 treats the resource path as relative to OAuth site URL* and generates this URL:
`https://localhost:8075/imagefactory/imagefactory/builders`
I'm not sure which OAuth behavior (0.4.4 vs. 0.4.6) is right. Does anyone have an opinion on this?
If 0.4.6 is the right behavior, we'll have to change our code [2] to work with it. Shouldn't be very hard, but worst case scenario is another dependency-version-specific code.
If 0.4.4 is the right behavior, we should stick to 0.4.4. This means fixing the OAuth dependency version in aeolus-image.gemspec XOR (if changing gemspec would cause some trouble I failed to predict now) fixing the OAuth dependency version in both Gemfiles (Conductor, Aeolus-Image).
Any opinions on which road to take are very welcome.
J.
[1] http://isitfedoraruby.com/fedorarpms/rubygem-oauth
[2] https://github.com/aeolusproject/aeolus-image-rubygem/blob/6801a52797adae...
11 years, 8 months
EOS Deadlines--distant early warning
by steve linabery
Hi aeolus developers!
We are looking at a repo freeze on master branches on Wednesday, September 5, EOD in the USA.
With the US Labor Day holiday in there, that makes for a pretty short sprint; heads up!
Best wishes for a productive sprint,
Steve|eggs
Software Engineer, Red Hat, Inc
11 years, 8 months
Coding Guidelines: Instance variables in views
by Matt Wagner
Hi folks,
I've noticed that we've been objecting to patches using instance
variables to pass information to views, so I went to see our coding
guidelines page[1] to read about why.
It makes very clear that it's bad, but it doesn't really explain the
right way. I'd hoped that the Coding Guidelines page would be more of a
guide on how to do things the right way.
I've really only found one blog post[2] that addresses the issue, and it
doesn't really give a great example. It still uses an instance variable
in the controller, but inside of a view it passes it as a local
variable. It's more specific, sure, but it's not abundantly clear how
that actually makes anything better, or why an instance variable from
the controller to the view is okay but a view to a partial is not okay.
Can someone with a more concrete understanding of the right way update
the wiki page, or send me some pointers so I can do so? I'd love for the
page to show the right way, maybe an example of rewriting the "bad way"
into the right way, rather than just giving a stern warning that it's
bad.
-- Matt
[1]
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Coding_Guidelines
[2]
http://rails-bestpractices.com/posts/27-replace-instance-variable-with-lo...
11 years, 8 months
