Re: [Puppet Users] Service Resources and Selinux
Hi,
Thanks for the response. Really, I think the way I'm approaching this
is thinking about starting mysqld under the right selinux user context
so that it doesn't label its own files incorrectly. Every time a
database or table is created, MySQL will be creating it under the wrong
user context, and selinux will then go and reset it back.
I think maybe a wrapper script using runcon which invokes the mysqld
service under the correct context is going to be the way to go. Really
though, I'd hoped that puppet had some kind of provision for starting
services with the correct user context!
Just wondering if anyone else has had the same issue in the past, or do
they just ignore all those seluser notifications? :-)
Many thanks. Tom.
On 10/10/12 01:50, Peter Brown wrote:
You need to add a require to the service for the config files you are managing.
I find the best way to do that is put all the config files in a config
subclass and then require that in in the service.
On 10 October 2012 01:02, Tomt...@t0mb.net wrote:
Hi list,
I've got an issue at the moment, which isn't really a big problem, but an
untidy annoyance really, and I'd just like to understand what the best
practice might be when dealing with the issue.
As a really quick summary, the issue is that Puppet is starting up the
mysqld service for the first time as unconfined_u, and then when MySQL goes
and creates a load of its initial files also as unconfined_u, Puppet goes
and resets them all to system_u which is what they should be when checking
matchpathcon:
The thing is, because the service is started as unconfined_u, any
databases/tables that are created are going to inherit that, and puppet is
going to be resetting them.
For some more detail, I've written something which will set the mysqld_db_t
selinux file_context on my data directories which are in /home, and I have a
notify which will go and check and re-set the selinux file_context if there
are any changes in these directories. They're set to recurse, so to stop
Puppet changing things from unconfined_u to system_u on a regular basis, and
sending refresh notices to my Exec resources, I've set
selinux_ignore_defaults to true in my File resources.
This strikes me as a bit of a dirty way of doing things, and I was wondering
if anyone had any better ideas of how to manage this.
Please find below a sample of the relevant code - because I'm sure my
verbose description is probably leaving some people scratching their heads!
:) I was going to make the file_context stuff much more re-usable, but want
to get my head around the best practices first - as I'm not that experiened
with all of this stuff to be honest!
Many thanks. Tom.
# List of directories we're going to use with MySQL
$mysqldirs = [ /home/data, /home/logs, /home/mysqltmp, ]
# Set SELinux contexts
define add_selinux_context ($context = mysqld_db_t) {
file { $name:
ensure = directory,
owner = mysql,
group = mysql,
seltype = mysqld_db_t,
selinux_ignore_defaults = true,
recurse = true,
require = Package[mysql-server],
notify = [ Exec[add_file_context_${context}_${name}],
Exec[set_file_context_${context}_${name}], ],
}
# Set the default file_context regex for the path
exec { add_file_context_${context}_${name}:
command = semanage fcontext -a -t ${context} \${name}(/.*)?\,
unless = semanage fcontext -l | grep '^${name}(/.*)?:${context}:',
require = [ Package[policycoreutils-python], File[$name], ],
refreshonly = true,
}
# Reset the file_context using restorecon
exec { set_file_context_${context}_${name}:
command = restorecon -R ${name},
unless = ls -d --scontext ${name} | awk -F: '{print \$3}' | grep
\${context}\,
require = File[$name],
refreshonly = true,
}
}
add_selinux_context { $mysqldirs:
context = mysqld_db_t,
}
# Keep it running
service { mysqld:
ensure= running,
hasstatus = true,
require = [ Package[mysql-server], File[$mysqldirs], ]
}
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups Puppet
Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Service Resources and Selinux
Well, I've decided on a very simple way of doing this,
# Keep it running
service { mysqld:
ensure = running,
start = runcon -u system_u /etc/init.d/mysqld start,
hasrestart = false,
require= [ Package[mysql-server], File[$mysqldirs], ],
}
so, it starts under the correct selinux user context, and then using
restart on the init script is disabled so that it makes use of the start
command when doing a restart.
Not sure if this would be something that would make a good resource flag?
Many thanks. Tom.
On 10/10/12 07:55, Tom wrote:
Hi,
Thanks for the response. Really, I think the way I'm approaching this
is thinking about starting mysqld under the right selinux user context
so that it doesn't label its own files incorrectly. Every time a
database or table is created, MySQL will be creating it under the
wrong user context, and selinux will then go and reset it back.
I think maybe a wrapper script using runcon which invokes the mysqld
service under the correct context is going to be the way to go.
Really though, I'd hoped that puppet had some kind of provision for
starting services with the correct user context!
Just wondering if anyone else has had the same issue in the past, or
do they just ignore all those seluser notifications? :-)
Many thanks. Tom.
On 10/10/12 01:50, Peter Brown wrote:
You need to add a require to the service for the config files you are
managing.
I find the best way to do that is put all the config files in a config
subclass and then require that in in the service.
On 10 October 2012 01:02, Tomt...@t0mb.net wrote:
Hi list,
I've got an issue at the moment, which isn't really a big problem,
but an
untidy annoyance really, and I'd just like to understand what the best
practice might be when dealing with the issue.
As a really quick summary, the issue is that Puppet is starting up the
mysqld service for the first time as unconfined_u, and then when
MySQL goes
and creates a load of its initial files also as unconfined_u, Puppet
goes
and resets them all to system_u which is what they should be when
checking
matchpathcon:
The thing is, because the service is started as unconfined_u, any
databases/tables that are created are going to inherit that, and
puppet is
going to be resetting them.
For some more detail, I've written something which will set the
mysqld_db_t
selinux file_context on my data directories which are in /home, and
I have a
notify which will go and check and re-set the selinux file_context
if there
are any changes in these directories. They're set to recurse, so to
stop
Puppet changing things from unconfined_u to system_u on a regular
basis, and
sending refresh notices to my Exec resources, I've set
selinux_ignore_defaults to true in my File resources.
This strikes me as a bit of a dirty way of doing things, and I was
wondering
if anyone had any better ideas of how to manage this.
Please find below a sample of the relevant code - because I'm sure my
verbose description is probably leaving some people scratching their
heads!
:) I was going to make the file_context stuff much more re-usable,
but want
to get my head around the best practices first - as I'm not that
experiened
with all of this stuff to be honest!
Many thanks. Tom.
# List of directories we're going to use with MySQL
$mysqldirs = [ /home/data, /home/logs, /home/mysqltmp, ]
# Set SELinux contexts
define add_selinux_context ($context = mysqld_db_t) {
file { $name:
ensure = directory,
owner = mysql,
group = mysql,
seltype = mysqld_db_t,
selinux_ignore_defaults = true,
recurse = true,
require = Package[mysql-server],
notify = [ Exec[add_file_context_${context}_${name}],
Exec[set_file_context_${context}_${name}], ],
}
# Set the default file_context regex for the path
exec { add_file_context_${context}_${name}:
command = semanage fcontext -a -t ${context}
\${name}(/.*)?\,
unless = semanage fcontext -l | grep
'^${name}(/.*)?:${context}:',
require = [ Package[policycoreutils-python], File[$name], ],
refreshonly = true,
}
# Reset the file_context using restorecon
exec { set_file_context_${context}_${name}:
command = restorecon -R ${name},
unless = ls -d --scontext ${name} | awk -F: '{print \$3}'
| grep
\${context}\,
require = File[$name],
refreshonly = true,
}
}
add_selinux_context { $mysqldirs:
context = mysqld_db_t,
}
# Keep it running
service { mysqld:
ensure= running,
hasstatus = true,
require = [ Package[mysql-server], File[$mysqldirs], ]
}
--
You received this message because you are subscribed to the Google
Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
Re: [Puppet Users] Service Resources and Selinux
Tom,
It seems like having that as a parameter in the service type might be a
good idea worthy of at least some further discussion. Want to open a
feature request in Redmine to track it? I might (eventually) take a stab
at adding support for it.
Sean
On Wed, 2012-10-10 at 09:01 +0100, Tom wrote:
Well, I've decided on a very simple way of doing this,
# Keep it running
service { mysqld:
ensure = running,
start = runcon -u system_u /etc/init.d/mysqld start,
hasrestart = false,
require= [ Package[mysql-server], File[$mysqldirs], ],
}
so, it starts under the correct selinux user context, and then using
restart on the init script is disabled so that it makes use of the start
command when doing a restart.
Not sure if this would be something that would make a good resource flag?
Many thanks. Tom.
On 10/10/12 07:55, Tom wrote:
Hi,
Thanks for the response. Really, I think the way I'm approaching this
is thinking about starting mysqld under the right selinux user context
so that it doesn't label its own files incorrectly. Every time a
database or table is created, MySQL will be creating it under the
wrong user context, and selinux will then go and reset it back.
I think maybe a wrapper script using runcon which invokes the mysqld
service under the correct context is going to be the way to go.
Really though, I'd hoped that puppet had some kind of provision for
starting services with the correct user context!
Just wondering if anyone else has had the same issue in the past, or
do they just ignore all those seluser notifications? :-)
Many thanks. Tom.
On 10/10/12 01:50, Peter Brown wrote:
You need to add a require to the service for the config files you are
managing.
I find the best way to do that is put all the config files in a config
subclass and then require that in in the service.
On 10 October 2012 01:02, Tomt...@t0mb.net wrote:
Hi list,
I've got an issue at the moment, which isn't really a big problem,
but an
untidy annoyance really, and I'd just like to understand what the best
practice might be when dealing with the issue.
As a really quick summary, the issue is that Puppet is starting up the
mysqld service for the first time as unconfined_u, and then when
MySQL goes
and creates a load of its initial files also as unconfined_u, Puppet
goes
and resets them all to system_u which is what they should be when
checking
matchpathcon:
The thing is, because the service is started as unconfined_u, any
databases/tables that are created are going to inherit that, and
puppet is
going to be resetting them.
For some more detail, I've written something which will set the
mysqld_db_t
selinux file_context on my data directories which are in /home, and
I have a
notify which will go and check and re-set the selinux file_context
if there
are any changes in these directories. They're set to recurse, so to
stop
Puppet changing things from unconfined_u to system_u on a regular
basis, and
sending refresh notices to my Exec resources, I've set
selinux_ignore_defaults to true in my File resources.
This strikes me as a bit of a dirty way of doing things, and I was
wondering
if anyone had any better ideas of how to manage this.
Please find below a sample of the relevant code - because I'm sure my
verbose description is probably leaving some people scratching their
heads!
:) I was going to make the file_context stuff much more re-usable,
but want
to get my head around the best practices first - as I'm not that
experiened
with all of this stuff to be honest!
Many thanks. Tom.
# List of directories we're going to use with MySQL
$mysqldirs = [ /home/data, /home/logs, /home/mysqltmp, ]
# Set SELinux contexts
define add_selinux_context ($context = mysqld_db_t) {
file { $name:
ensure = directory,
owner = mysql,
group = mysql,
seltype = mysqld_db_t,
selinux_ignore_defaults = true,
recurse = true,
require = Package[mysql-server],
notify = [ Exec[add_file_context_${context}_${name}],
Exec[set_file_context_${context}_${name}], ],
}
# Set the default file_context regex for the path
exec { add_file_context_${context}_${name}:
command = semanage fcontext -a -t ${context}
\${name}(/.*)?\,
unless = semanage fcontext -l | grep
'^${name}(/.*)?:${context}:',
require = [ Package[policycoreutils-python], File[$name], ],
refreshonly = true,
}
# Reset the file_context using restorecon
exec { set_file_context_${context}_${name}:
command = restorecon -R ${name},
unless = ls -d --scontext ${name} | awk -F: '{print \$3}'
| grep
\${context}\,
require = File[$name],
Re: [Puppet Users] Service Resources and Selinux
On Wednesday, October 10, 2012 7:08:21 AM UTC-5, Sean Millichamp wrote: Tom, It seems like having that as a parameter in the service type might be a good idea worthy of at least some further discussion. [T]hat refers to an SELinux context in which the service management commands are supposed to be executed? Want to open a feature request in Redmine to track it? I might (eventually) take a stab at adding support for it. As you might infer from my other response, I think that's altogether the wrong approach. Puppet should not provide such a parameter, because it invites users to misconfigure their systems (by using the proposed parameter as a workaround). Services' configuration and the system tools should control services' runtime parameters, including their SELinux context. Otherwise, the service cannot be started properly during system initialization, and it can easily be (re)started incorrectly during manual administration. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/EpH0O46rKWQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Service Resources and Selinux
You need to add a require to the service for the config files you are managing.
I find the best way to do that is put all the config files in a config
subclass and then require that in in the service.
On 10 October 2012 01:02, Tom t...@t0mb.net wrote:
Hi list,
I've got an issue at the moment, which isn't really a big problem, but an
untidy annoyance really, and I'd just like to understand what the best
practice might be when dealing with the issue.
As a really quick summary, the issue is that Puppet is starting up the
mysqld service for the first time as unconfined_u, and then when MySQL goes
and creates a load of its initial files also as unconfined_u, Puppet goes
and resets them all to system_u which is what they should be when checking
matchpathcon:
The thing is, because the service is started as unconfined_u, any
databases/tables that are created are going to inherit that, and puppet is
going to be resetting them.
For some more detail, I've written something which will set the mysqld_db_t
selinux file_context on my data directories which are in /home, and I have a
notify which will go and check and re-set the selinux file_context if there
are any changes in these directories. They're set to recurse, so to stop
Puppet changing things from unconfined_u to system_u on a regular basis, and
sending refresh notices to my Exec resources, I've set
selinux_ignore_defaults to true in my File resources.
This strikes me as a bit of a dirty way of doing things, and I was wondering
if anyone had any better ideas of how to manage this.
Please find below a sample of the relevant code - because I'm sure my
verbose description is probably leaving some people scratching their heads!
:) I was going to make the file_context stuff much more re-usable, but want
to get my head around the best practices first - as I'm not that experiened
with all of this stuff to be honest!
Many thanks. Tom.
# List of directories we're going to use with MySQL
$mysqldirs = [ /home/data, /home/logs, /home/mysqltmp, ]
# Set SELinux contexts
define add_selinux_context ($context = mysqld_db_t) {
file { $name:
ensure = directory,
owner = mysql,
group = mysql,
seltype = mysqld_db_t,
selinux_ignore_defaults = true,
recurse = true,
require = Package[mysql-server],
notify = [ Exec[add_file_context_${context}_${name}],
Exec[set_file_context_${context}_${name}], ],
}
# Set the default file_context regex for the path
exec { add_file_context_${context}_${name}:
command = semanage fcontext -a -t ${context} \${name}(/.*)?\,
unless = semanage fcontext -l | grep '^${name}(/.*)?:${context}:',
require = [ Package[policycoreutils-python], File[$name], ],
refreshonly = true,
}
# Reset the file_context using restorecon
exec { set_file_context_${context}_${name}:
command = restorecon -R ${name},
unless = ls -d --scontext ${name} | awk -F: '{print \$3}' | grep
\${context}\,
require = File[$name],
refreshonly = true,
}
}
add_selinux_context { $mysqldirs:
context = mysqld_db_t,
}
# Keep it running
service { mysqld:
ensure= running,
hasstatus = true,
require = [ Package[mysql-server], File[$mysqldirs], ]
}
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
