I just updated a test system running fedora 11 from cobbler 1.6.6 to cobbler 2.0.3.1 and came across something rather unsettling, I hope it can be repaired by updating my understanding of cobbler.
One of my distro configurations points to a kernel image which is now unavailable, I can replace the kernel image, but what unsettles me is that cobbler won't start, and if I wanted to alter the configuration I would need to communicate with a running cobbler server.
I while I am going to agree that a mis-configured server should not start, my problem is that cobbler is configured through access to the running server. Now I need to repair the paths manually or remove all of the json files which referenced my distro while crossing my fingers that I don't disturb the cobbler internals somehow.
I am going to recommend that the behavior be such that a mis-configured element would raise a warning or log message rather than preventing the service from being reconfigured. From a design perspective, since the decision has been made to ensure a working configuration through the api, then the api should not prevent repairing a configuration. This is especially true because of the disparate external circumstances in which the configuration can be compromised.
-Tom Hatch
Excerpts from Thomas S Hatch's message of Fri Apr 02 17:27:36 -0400 2010:
I just updated a test system running fedora 11 from cobbler 1.6.6 to cobbler 2.0.3.1 and came across something rather unsettling, I hope it can be repaired by updating my understanding of cobbler.
One of my distro configurations points to a kernel image which is now unavailable, I can replace the kernel image, but what unsettles me is that cobbler won't start, and if I wanted to alter the configuration I would need to communicate with a running cobbler server.
This isn't new with cobbler 2.0. The new part of cobbler 2.0 though is that the cli now goes through cobblerd, which probably makes this harder to fix than it once was.
I while I am going to agree that a mis-configured server should not start, my problem is that cobbler is configured through access to the running server. Now I need to repair the paths manually or remove all of the json files which referenced my distro while crossing my fingers that I don't disturb the cobbler internals somehow.
I am going to recommend that the behavior be such that a mis-configured element would raise a warning or log message rather than preventing the service from being reconfigured. From a design perspective, since the decision has been made to ensure a working configuration through the api, then the api should not prevent repairing a configuration. This is especially true because of the disparate external circumstances in which the configuration can be compromised.
We have wanted to do this for quite some time, but we haven't been able to agree on the proper action to take. Should the bad object be marked as bad and then all downstream objects simply not show up until it is fixed? Or should we throw an error and refuse to do any kickstarting till everything is fixed. One could make the argument that cobbler should just let things go along even if it knows that an error will be generated later on in the process. I'm not sure what the right behavior is here. Does anyone else have ideas on what the right behavior is? I'm a fan of marking the object bad and not showing any downstream stuff.
On Mon, Apr 5, 2010 at 9:08 AM, Scott Henson shenson@redhat.com wrote:
Excerpts from Thomas S Hatch's message of Fri Apr 02 17:27:36 -0400 2010:
I just updated a test system running fedora 11 from cobbler 1.6.6 to
cobbler
2.0.3.1 and came across something rather unsettling, I hope it can be repaired by updating my understanding of cobbler.
One of my distro configurations points to a kernel image which is now unavailable, I can replace the kernel image, but what unsettles me is
that
cobbler won't start, and if I wanted to alter the configuration I would
need
to communicate with a running cobbler server.
This isn't new with cobbler 2.0. The new part of cobbler 2.0 though is that the cli now goes through cobblerd, which probably makes this harder to fix than it once was.
I while I am going to agree that a mis-configured server should not
start,
my problem is that cobbler is configured through access to the running server. Now I need to repair the paths manually or remove all of the
json
files which referenced my distro while crossing my fingers that I don't disturb the cobbler internals somehow.
I am going to recommend that the behavior be such that a mis-configured element would raise a warning or log message rather than preventing the service from being reconfigured. From a design
perspective,
since the decision has been made to ensure a working configuration
through
the api, then the api should not prevent repairing a configuration. This is especially true because of the disparate external circumstances in
which
the configuration can be compromised.
We have wanted to do this for quite some time, but we haven't been able to agree on the proper action to take. Should the bad object be marked as bad and then all downstream objects simply not show up until it is fixed? Or should we throw an error and refuse to do any kickstarting till everything is fixed. One could make the argument that cobbler should just let things go along even if it knows that an error will be generated later on in the process. I'm not sure what the right behavior is here. Does anyone else have ideas on what the right behavior is? I'm a fan of marking the object bad and not showing any downstream stuff. -- Scott Henson Red Hat CIS Operator WVU Alum BSAE/BSME _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
I will heartily agree that this is an in depth problem. For what it is worth, I would think that the system should start, that error messages should be logged, and that kickstarts should not be made available on broken systems.
This would allow for easy debugging of what could be a complicated issue and avoid the problem of installs failing halfway.
My other suggestion would be that the service not start but that an external facility to edit the configuration would exist.
I would also request that distros/profiles/systems could be temporarily disabled by the admin, this should simplify if an old package tree is removed, or if company policy changes to stop deploying a system of a certain type but the configuration should be preserved. Disabling would also allow mis-configured components to be safely placed on the back burner until ample time to repair the problem without disabling cobbler altogether.
Perhaps someday I can break from my hectic schedule to throw some code your way, although I think it may never happen :)
-Tom Hatch
On Apr 5, 2010, at 11:08 AM, Scott Henson wrote:
Excerpts from Thomas S Hatch's message of Fri Apr 02 17:27:36 -0400 2010:
I just updated a test system running fedora 11 from cobbler 1.6.6 to cobbler 2.0.3.1 and came across something rather unsettling, I hope it can be repaired by updating my understanding of cobbler.
One of my distro configurations points to a kernel image which is now unavailable, I can replace the kernel image, but what unsettles me is that cobbler won't start, and if I wanted to alter the configuration I would need to communicate with a running cobbler server.
This isn't new with cobbler 2.0. The new part of cobbler 2.0 though is that the cli now goes through cobblerd, which probably makes this harder to fix than it once was.
I while I am going to agree that a mis-configured server should not start, my problem is that cobbler is configured through access to the running server. Now I need to repair the paths manually or remove all of the json files which referenced my distro while crossing my fingers that I don't disturb the cobbler internals somehow.
I am going to recommend that the behavior be such that a mis-configured element would raise a warning or log message rather than preventing the service from being reconfigured. From a design perspective, since the decision has been made to ensure a working configuration through the api, then the api should not prevent repairing a configuration. This is especially true because of the disparate external circumstances in which the configuration can be compromised.
We have wanted to do this for quite some time, but we haven't been able to agree on the proper action to take. Should the bad object be marked as bad and then all downstream objects simply not show up until it is fixed? Or should we throw an error and refuse to do any kickstarting till everything is fixed. One could make the argument that cobbler should just let things go along even if it knows that an error will be generated later on in the process. I'm not sure what the right behavior is here. Does anyone else have ideas on what the right behavior is? I'm a fan of marking the object bad and not showing any downstream stuff. -- Scott Henson Red Hat CIS Operator WVU Alum BSAE/BSME _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
My opinion is that if there is any problem parsing the configs, then we should not assume that the operator knows what he/she is doing. Fail to start with a descriptive error: Could not find resource X referenced in Y. I recently screwed up our configs and left a stray file laying around. Cobbler didn't know what to do with this. The 'check' command failed ungracefully since it couldn't parse the configs.
-jesse
cobbler@lists.fedorahosted.org
-
Jesse Callaway -
Scott Henson -
Thomas S Hatch