Re: [Linux-ha-dev] New OCF RA: symlink
On 5/5/2011 at 12:36 AM, Lars Ellenberg wrote: > On Wed, May 04, 2011 at 03:06:27PM +0200, Florian Haas wrote: > > Coming back to this one, as the discussion seems to have died down. > > > > On 2011-04-20 19:00, Lars Ellenberg wrote: > > > Oh, well, thinking about non-roots that may have cibadmin karma, > > > they now can configure a resource that will remove /etc/passwd. > > > I'm not sure if I like that. > > > > > > How about a staged system? Double symlinks? > > > Similar to the alternatives system in Debian or others. > > > > > > The RA will force a single directory that will contain the indirection > > > symlinks, and will sanitize (or force) link names to not contain slashes. > > > > > > The real symlinks will point to that indirection symlink, which will > > > point to the end location. > > > > > > /etc/postfix/main.cf > > >-> /var/lib/wherever-indirection-dir/postfix_main.cf <<<=== > > > -> /mnt/somewhere/you/want/to/point/to/main.cf > > > > > > And <<<=== will be managed by the resource agent. > > > > Considering we have an "anything" resource agent which, well, lets us do > > anything, I consider this pointless cluttering of the resource agent > > which creates a false sense of security. Thoughts? > > Trying to think out loud... > There are a few aspects. > > * if we don't have ACLs, anyone with write access to the CIB > is de facto root on the cluster nodes. Which makes privilege > escalation bugs non-existent by definition ;-) > > * potential privilege escalation > > Well, to make this an issue, we would need to establish that >* the cib ACL system is in place, >* and used, >* and "properly" configured, > which would probably also mean that access would be limited to only > certain resource agent types. The ACL system allows one to determine who can read and write particular sections or attributes of the CIB, but doesn't say anything about what values can be written. So, if one has write access to a given resource, (or the entire resources section), one can invoke any RA on the system. > Most likely the ACL will be short as well: one role that can do > "cleanup" and otherwise only view things, > one role that can do everything (equivalent to root). Yes. It's worth nothing that you can restrict certain types of operation by what attributes can be written. See "Example Role: 'Operator' Access" at: http://www.clusterlabs.org/doc/acls.html This allows maintenance mode to be turned on and off, take nodes on and off standby, start. stop, promote, manage, unmanage and migrate resources, but doesn't allow reconfiguration of any resource parameters (type, meta attributes, ops). This particular example might be too permissive for some cases, but should serve to give an idea of what granularity of control we have right now. > Services running under Pacemaker control are probably "critical", > so a malicious person with even only "stop" access on the CIB > can do a DoS. I guess we have to assume people with any write access > at all to the CIB are "trusted", and not malicious. One would hope so :) > Adding more "insecure" RAs would just keep the white list shorter. > No problem with me. > > White list would probably be really short anyways. > > Still we may want to try and limit the potential damage > that can be done by roles that have only limited rights > (start/stop/reconfigure existing). > > /me not sure about all this ACL stuff anyways, > I'd try to avoid it where ever possible ;-) > > * limit potential damage on "accidental carelessness" > > Well, yes, I think that is something we could aim for, too. > > And a some more thoughts, but I would probably need a few beers to make > them appear coherent even to myself ;-) /me makes a note to lay in a stock of beer for when those extra thoughts arrive. Cheers, Tim -- Tim Serong Senior Clustering Engineer, OPS Engineering, Novell Inc. ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] [Openais] An OCF agent for LXC (Linux Containers) - Linux-HA-Dev Digest, Vol 90, Issue 6
Florian/Team There was an error in the GIT-Hub version that was causing my re-base attempts to fail, so I was forced to try to bring my "last known good" version to the same configuration (mostly successful). I have since found the error in the GIT-Hub version (the initialisation section was wrong, the meta-data error was a 'red herring') so have been found and resolved so I have done an actual re-base now based on the GIT-Hub version. Changes: 1. Corrected error in utilisation causing ocf to fail in HB_GUI. 2. Added "information" to stop section, to provide more feedback on container shutdown/stop (and to assist with future development of "containers using alternate 'init' systems"). Regards Darren On Wed, 2011-05-04 at 12:00 -0600, linux-ha-dev-requ...@lists.linux-ha.org wrote: > > Florian/Team > > > > I have now updated my "re-based" ocf file to include the > "experimental" > > support for upstart and systemd using containers. > > > > I can confirm that this is still working correctly for containers > > running 'sysv init' and "in theory" should now also work for > containers > > using 'upstart' and 'systemd'. > > > > I'm currently doing a "crash course' in installing containers to use > > these 'init replacments' but have not yet succedded in testing > either > > 'upstart' or 'systemd' containers yet. > > > > If there is anyone with a better understanding of LXC containers and > > one/both of these other 'init systems', please contact me as your > > information/assistance would be invaluable. > > OK, updated my git branch. You really want to double check your > "rebasing" method; you're constantly re-introducing things that I've > removed or fixed in earlier commits. > > Florian > lxc Description: application/shellscript ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Linux-HA-Dev Digest, Vol 90, Issue 6
Florian/Team There was an error in the GIT-Hub version that was causing my re-base attempts to fail, so I was forced to try to bring my "last known good" version to the same configuration (mostly successful). I have since found the error in the GIT-Hub version (the initialisation section was wrong, the meta-data error was a 'red herring') so have been found and resolved so I have done an actual re-base now based on the GIT-Hub version. Changes: 1. Corrected error in utilisation causing ocf to fail in HB_GUI. 2. Added "information" to stop section, to provide more feedback on container shutdown/stop (and to assist with future development of "containers using alternate 'init' systems"). Regards Darren On Wed, 2011-05-04 at 12:00 -0600, linux-ha-dev-requ...@lists.linux-ha.org wrote: > > Florian/Team > > > > I have now updated my "re-based" ocf file to include the > "experimental" > > support for upstart and systemd using containers. > > > > I can confirm that this is still working correctly for containers > > running 'sysv init' and "in theory" should now also work for > containers > > using 'upstart' and 'systemd'. > > > > I'm currently doing a "crash course' in installing containers to use > > these 'init replacments' but have not yet succedded in testing > either > > 'upstart' or 'systemd' containers yet. > > > > If there is anyone with a better understanding of LXC containers and > > one/both of these other 'init systems', please contact me as your > > information/assistance would be invaluable. > > OK, updated my git branch. You really want to double check your > "rebasing" method; you're constantly re-introducing things that I've > removed or fixed in earlier commits. > > Florian > lxc Description: application/shellscript ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] New OCF RA: symlink
On Wed, May 04, 2011 at 03:06:27PM +0200, Florian Haas wrote: > Coming back to this one, as the discussion seems to have died down. > > On 2011-04-20 19:00, Lars Ellenberg wrote: > > Oh, well, thinking about non-roots that may have cibadmin karma, > > they now can configure a resource that will remove /etc/passwd. > > I'm not sure if I like that. > > > > How about a staged system? Double symlinks? > > Similar to the alternatives system in Debian or others. > > > > The RA will force a single directory that will contain the indirection > > symlinks, and will sanitize (or force) link names to not contain slashes. > > > > The real symlinks will point to that indirection symlink, which will > > point to the end location. > > > > /etc/postfix/main.cf > >-> /var/lib/wherever-indirection-dir/postfix_main.cf <<<=== > > -> /mnt/somewhere/you/want/to/point/to/main.cf > > > > And <<<=== will be managed by the resource agent. > > Considering we have an "anything" resource agent which, well, lets us do > anything, I consider this pointless cluttering of the resource agent > which creates a false sense of security. Thoughts? Trying to think out loud... There are a few aspects. * if we don't have ACLs, anyone with write access to the CIB is de facto root on the cluster nodes. Which makes privilege escalation bugs non-existent by definition ;-) * potential privilege escalation Well, to make this an issue, we would need to establish that * the cib ACL system is in place, * and used, * and "properly" configured, which would probably also mean that access would be limited to only certain resource agent types. Most likely the ACL will be short as well: one role that can do "cleanup" and otherwise only view things, one role that can do everything (equivalent to root). Services running under Pacemaker control are probably "critical", so a malicious person with even only "stop" access on the CIB can do a DoS. I guess we have to assume people with any write access at all to the CIB are "trusted", and not malicious. Adding more "insecure" RAs would just keep the white list shorter. No problem with me. White list would probably be really short anyways. Still we may want to try and limit the potential damage that can be done by roles that have only limited rights (start/stop/reconfigure existing). /me not sure about all this ACL stuff anyways, I'd try to avoid it where ever possible ;-) * limit potential damage on "accidental carelessness" Well, yes, I think that is something we could aim for, too. And a some more thoughts, but I would probably need a few beers to make them appear coherent even to myself ;-) -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] New OCF RA: symlink
On 2011-04-20 14:37, Florian Haas wrote: > On 2011-04-20 11:41, Dominik Klein wrote: >> Hi >> >> I wrote a new RA that can manage a symlink. >> >> Configuration: >> >> primitive mylink ocf:heartbeat:symlink \ >> params link="/tmp/link" target="/tmp/target" \ >> op monitor interval="15" timeout="15" >> >> This will basically >> ln -s /tmp/target /tmp/link >> >> hth >> Dominik > > Dominik doesn't have a github repo yet, so I added this to a separate > branch in mine. The current revision is here: > > https://github.com/fghaas/resource-agents/blob/symlink/heartbeat/symlink > > Please comment freely. Thanks! I've just responded to two comments from Lars and Alan and I'd appreciate more. As of right now I don't see any show stoppers and I wouldn't like to hold up Dominik's contribution much longer. Unless I hear any valid objections, I intend to merge this new RA next Monday. Thanks! Cheers, Florian signature.asc Description: OpenPGP digital signature ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] New OCF RA: symlink
On 2011-04-22 14:25, Alan Robertson wrote: > Drbdlinks was never converted to an OCF RA, that I recall. It handles > cases of needing to restart the logging system when you changed symlnks > around - mainly for chroot services. I've used it for many years. You > can find the source for it here: > http://www.tummy.com/Community/software/drbdlinks/ > > It's pretty well thought out, and works quite well. I'd certainly look > it over before reinventing the wheel. AFAICS drbdlinks does some things on its own which in a Pacemaker cluster would be under Pacemaker control (restarting daemons, for example). The symlink RA does none of this, it's simple and effective and ties in quite well with Pacemaker management. Cheers, Florian signature.asc Description: OpenPGP digital signature ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] New OCF RA: symlink
Coming back to this one, as the discussion seems to have died down. On 2011-04-20 19:00, Lars Ellenberg wrote: > Oh, well, thinking about non-roots that may have cibadmin karma, > they now can configure a resource that will remove /etc/passwd. > I'm not sure if I like that. > > How about a staged system? Double symlinks? > Similar to the alternatives system in Debian or others. > > The RA will force a single directory that will contain the indirection > symlinks, and will sanitize (or force) link names to not contain slashes. > > The real symlinks will point to that indirection symlink, which will > point to the end location. > > /etc/postfix/main.cf >-> /var/lib/wherever-indirection-dir/postfix_main.cf <<<=== > -> /mnt/somewhere/you/want/to/point/to/main.cf > > And <<<=== will be managed by the resource agent. Considering we have an "anything" resource agent which, well, lets us do anything, I consider this pointless cluttering of the resource agent which creates a false sense of security. Thoughts? Cheers, Florian signature.asc Description: OpenPGP digital signature ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] cluster-glue-1.0.7: WARNING: linux/errqueue.h: present but cannot be compiled
On Thu, Apr 28, 2011 at 04:52:21PM +0200, Ermete Gaudenzi wrote: > Ok with the patch the warning message disappears and the program works. > In config.log the checks for errqueue.h have the same results (present > but not usable). OK. Thanks for testing. > The same problem is found on pacemaker-1.0.10 > downloaded from: > http://hg.clusterlabs.org/pacemaker/stable-1.0/archive/da7075976b5f.tar.bz2 > > Will this be fixed in next release? Yes. Thanks, Dejan > Thanks for your help ;-) > Ermete Gaudenzi > ___ > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] [Openais] An OCF agent for LXC (Linux Containers) - Linux-HA-Dev Digest, Vol 90, Issue 3
On 05/04/2011 10:52 AM, Darren Thompson wrote: > Florian/Team > > I have now updated my "re-based" ocf file to include the "experimental" > support for upstart and systemd using containers. > > I can confirm that this is still working correctly for containers > running 'sysv init' and "in theory" should now also work for containers > using 'upstart' and 'systemd'. > > I'm currently doing a "crash course' in installing containers to use > these 'init replacments' but have not yet succedded in testing either > 'upstart' or 'systemd' containers yet. > > If there is anyone with a better understanding of LXC containers and > one/both of these other 'init systems', please contact me as your > information/assistance would be invaluable. OK, updated my git branch. You really want to double check your "rebasing" method; you're constantly re-introducing things that I've removed or fixed in earlier commits. Florian signature.asc Description: OpenPGP digital signature ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] [Openais] An OCF agent for LXC (Linux Containers) - Linux-HA-Dev Digest, Vol 90, Issue 3
Florian/Team I have now updated my "re-based" ocf file to include the "experimental" support for upstart and systemd using containers. I can confirm that this is still working correctly for containers running 'sysv init' and "in theory" should now also work for containers using 'upstart' and 'systemd'. I'm currently doing a "crash course' in installing containers to use these 'init replacments' but have not yet succedded in testing either 'upstart' or 'systemd' containers yet. If there is anyone with a better understanding of LXC containers and one/both of these other 'init systems', please contact me as your information/assistance would be invaluable. Darren On Tue, 2011-05-03 at 12:00 -0600, linux-ha-dev-requ...@lists.linux-ha.org wrote: > Florian/Team > > Sorry I did not read this sooner, my last update will still have be > messy for you (sorry). > > I'll grab a copy of the current version and re-base my work on that. > > I see that you have streamlined it quite a bit, I'll test it in my > environment to ensure it's working as expected (I note that the > parameters have changed names and some functionality so will re-create > my cluster/lxc/containers using this and re-test). > > Darre lxc Description: application/shellscript ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Linux-HA-Dev Digest, Vol 90, Issue 4
Florian/Team I have succeeded in re-basing my work on the version in the repository. That should make re-integrating my changes much more straight forward.. It is much more succinct now. Changes in this version: 1. Re-based on Florian's version in "https://github.com/fghaas/resource-agents/blob/lxc/heartbeat/lxc"; 2. Removed "root" variable requirements (it was only used once and did not add significant value to configuration) 3. Removed mention of "root" from verify and stop sections 3. Cleaned up and expanded meta-data section, added to descriptions etc 4. remove superfluous "cd" in start section as no longer requires with full config path specified. I really do not know what happend to my first few attempts at re-basing, I'm assuming an invalid character got into the file somewhere... Darren On Wed, 2011-05-04 at 00:44 -0600, linux-ha-dev-requ...@lists.linux-ha.org wrote: > Florian > > I have tried to re-base on your version but it just will not run for > me. > > I keep getting "Failed to parse the metadata of LXC" syntax error line > 1, column 1" > > I've no idea where this error is as it all looks fine... > > I'll attach my copy and a screen-shot of the error, HELP!!! > > Darren lxc Description: application/shellscript ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] [Openais] An OCF agent for LXC (Linux Containers) - Linux-HA-Dev Digest, Vol 90, Issue 2
On 05/04/2011 09:09 AM, Florian Haas wrote:
> On 05/04/2011 08:44 AM, Darren Thompson wrote:
>> Florian
>>
>> I have tried to re-base on your version but it just will not run for me.
>>
>> I keep getting "Failed to parse the metadata of LXC" syntax error line
>> 1, column 1"
>>
>> I've no idea where this error is as it all looks fine...
>>
>> I'll attach my copy and a screen-shot of the error, HELP!!!
>
> It's probably not a wise approach to "test" with the GUI while you're
> not even sure the resource agent will run. You will have to start the
> script from the command line and see where your error is coming from.
Btw, your patch contains this:
diff --git a/heartbeat/lxc b/heartbeat/lxc
index 25ef6e3..9819a47 100755
--- a/heartbeat/lxc
+++ b/heartbeat/lxc
@@ -123,7 +123,6 @@ LXC_start() {
if ! LXC_monitor ; then
touch $TRANS_RES_STATE
ocf_log info "Starting" ${OCF_RESKEY_container}
- cd "`dirname ${OCF_RESKEY_config`"
ocf_run ${STARTCMD} || exit $OCF_ERR_GENERIC
else
# If already running, consider start
successful
Sorry, that was a typo on my part, should have been cd "`dirname
${OCF_RESKEY_config}`" (with closing brace) of course. Should I correct
the typo, or can we drop that line altogether?
Cheers,
Florian
signature.asc
Description: OpenPGP digital signature
___
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] [Openais] An OCF agent for LXC (Linux Containers) - Linux-HA-Dev Digest, Vol 90, Issue 2
On 05/04/2011 08:44 AM, Darren Thompson wrote: > Florian > > I have tried to re-base on your version but it just will not run for me. > > I keep getting "Failed to parse the metadata of LXC" syntax error line > 1, column 1" > > I've no idea where this error is as it all looks fine... > > I'll attach my copy and a screen-shot of the error, HELP!!! It's probably not a wise approach to "test" with the GUI while you're not even sure the resource agent will run. You will have to start the script from the command line and see where your error is coming from. Florian signature.asc Description: OpenPGP digital signature ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
