Hi all,
as you know, I am working on the modular structure of rsyslog v3. I am
currently revisiting gss-api support. I notice that with the current
omfwd, it will be extremely hard to separate gss-api support into its
own module. Doing so will break backward compatibility to the
configuration file.
GSS-API has been out only for a few days, and mostly over the holiday
period. So it is much less of a concern if we introduce now some changes
that will case rsyslog.conf format modifications. Much less trouble than
when we release v2, a release expected to be in wide use for at least
half a year, if not much longer. V2 released with the current syntax
would require me to do some tricks in v3 to keep compatibility. Quite
complex.
So I decided to create a omgssapi for v3 and extract the gss-api code
from omfwd. It looks like this can be done without too much code
duplication. There will be some duplicate code, but it will shrink as v3
continues to be developed. Once I have a good working version, which I
expect very soon, I will backport that to the v1/2 source tree. I'll
then do a new v1 release with a slightly incompatible gss-api config
file syntax. After this is out for a few days, I hope I can than finally
push out that version as v2.
I hope this is a good decision. I think it will save us major future
trouble at the expense of a relatively slight disturbance in the late v1
timeline. I guess most user's won't even notice there is a change.
As always, Feedback is appreciated.
Rainer
as you know, I am working on the modular structure of rsyslog v3. I am
currently revisiting gss-api support. I notice that with the current
omfwd, it will be extremely hard to separate gss-api support into its
own module. Doing so will break backward compatibility to the
configuration file.
GSS-API has been out only for a few days, and mostly over the holiday
period. So it is much less of a concern if we introduce now some changes
that will case rsyslog.conf format modifications. Much less trouble than
when we release v2, a release expected to be in wide use for at least
half a year, if not much longer. V2 released with the current syntax
would require me to do some tricks in v3 to keep compatibility. Quite
complex.
So I decided to create a omgssapi for v3 and extract the gss-api code
from omfwd. It looks like this can be done without too much code
duplication. There will be some duplicate code, but it will shrink as v3
continues to be developed. Once I have a good working version, which I
expect very soon, I will backport that to the v1/2 source tree. I'll
then do a new v1 release with a slightly incompatible gss-api config
file syntax. After this is out for a few days, I hope I can than finally
push out that version as v2.
I hope this is a good decision. I think it will save us major future
trouble at the expense of a relatively slight disturbance in the late v1
timeline. I guess most user's won't even notice there is a change.
As always, Feedback is appreciated.
Rainer