Sponsored development rlm_ldap and ocsp
Hello developers, for a projekt we need to keep the radius clients in LDAP. As this is not yet possible with rlm_ldap we would like to sponsor this development. Our requirements so far are: - created code should go in the official freeradius code base. - official invoice for our purchasing department. - LDAP schema oder schema enhancement for the clients with required attributes, ideally with oids from the freeradius projekt. Should be pretty easy as most of the needed code is already in rlm_sql and rlm_ldap. Please let me know what you think about this, and if someone is willing to do this please mail me your offer stating your timeframe and price. Additionally we might be interested to sponsor OCSP support for EAP-TLS, so i'd be happy to receive offers on this one too, though this one is not yet decided on internally. Kind regards, Stephan Jaeger EWE TEL GmbH
On 08/19/2010 04:27 AM, Stephan Jäger wrote:
Hello developers,
for a projekt we need to keep the radius clients in LDAP. As this is not yet possible with rlm_ldap we would like to sponsor this development.
Our requirements so far are:
- created code should go in the official freeradius code base. - official invoice for our purchasing department. - LDAP schema oder schema enhancement for the clients with required attributes, ideally with oids from the freeradius projekt.
Should be pretty easy as most of the needed code is already in rlm_sql and rlm_ldap.
Please let me know what you think about this, and if someone is willing to do this please mail me your offer stating your timeframe and price.
Additionally we might be interested to sponsor OCSP support for EAP-TLS, so i'd be happy to receive offers on this one too, though this one is not yet decided on internally.
Welcome to the power of open source, you don't have to pay to get this done. I've already implemented storing clients in LDAP here at Red Hat. At Red Hat we believe in sharing and supporting the community. You're more than welcome to the code. Our plan all along had been to send the code upstream (i.e. give it to FreeRADIUS) but the project this was done for was put on hold and I was reassigned. We still plan on doing this but at a later date because of our internal schedules. Now that the FreeRADIUS code base is in git it makes doing this even easier. I will try to take some time, even if it's my personal time to dust off the code and get it merged into a git repo which I'll publish. Do you have a time frame you need this by? With respect to the OID's, we do have an LDAP schema defined but we used our own OID's out of expediency. It's trivial to change the OID's though. Alan does FreeRADIUS already have a block of OID's? If you would like to make a contribution may I suggest you donate something to the FreeRADIUS project and/or purchase a RHEL subscription if you happen to be using one of the RHEL clones. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
Welcome to the power of open source, you don't have to pay to get this done. I've already implemented storing clients in LDAP here at Red Hat. At Red Hat we believe in sharing and supporting the community. You're more than welcome to the code. Our plan all along had been to send the code upstream (i.e. give it to FreeRADIUS) but the project this was done for was put on hold and I was reassigned. We still plan on doing this but at a later date because of our internal schedules.
I've taken a short look at that code. It seems fine. But it will require porting to 2.x.
With respect to the OID's, we do have an LDAP schema defined but we used our own OID's out of expediency. It's trivial to change the OID's though. Alan does FreeRADIUS already have a block of OID's?
We have a private enterprise code, if that helps. See dictionary.freeradius. Alan DeKok.
On 08/19/2010 12:11 PM, Alan DeKok wrote:
John Dennis wrote:
Welcome to the power of open source, you don't have to pay to get this done. I've already implemented storing clients in LDAP here at Red Hat. At Red Hat we believe in sharing and supporting the community. You're more than welcome to the code. Our plan all along had been to send the code upstream (i.e. give it to FreeRADIUS) but the project this was done for was put on hold and I was reassigned. We still plan on doing this but at a later date because of our internal schedules.
I've taken a short look at that code. It seems fine. But it will require porting to 2.x.
I've just started porting it using the 2.1.10 git branch. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Attached is a git format patch which adds support for storing clients in LDAP. The necessary schema can be found in doc/examples/389_ds_schema.ldif. This is schema ldif file suitable for use with 389-ds (the standard LDAP server shipped with Fedora and RHEL which over the years with different versions has been known under a variety of names, Netscape Directory Server, iPlanet, Sun Directory Server, Red Hat Directory Server, Fedora Directory server). The patch was against the 2.1.10 branch. Here are a few quick notes. * Its had only light testing, but seems to work O.K. It should probably be tested in different with different combinations of client specification. * I did add support for COA, but that's not tested. * When I was looking at the schema I noticed the OID's which are being used (in each of the schema files I looked at) are not registered and do not belong to FreeRADIUS (they belong to the GNOME name space and I believe the reason for that is GNOME had a block of OID's and for expediency they were "borrowed"). I did not update the other ldap schema files in the patch, the new schema should be reviewed first. The new attributes and object classes should then be merged into the other schema files. * The code to parse a client IP address is now duplicated in three places in the server, in client.c when reading the clients file, in rlm_sql.c and rlm_ldap.c. The code should probably be refactored so there is a common subroutine to do this. * The schema should be reviewed. One thing was immediately came to my mind was case sensitivity, right now the matching rules are case insenstive. Also the strings are defined to be ASCII (actually IA5). Perhaps the strings should be UTF-8 case sensitive. But that's less important than making sure the right attributes and object classes are defined and their naming makes sense. * The attribute names are hard coded in the source, but that's consistent with how the rest of rlm_ldap works, but that does mean you're tied to using the supplied schema. * I followed the existing indentation (each indent level is a tab character) which I personally dislike (I would prefer to see an indent of 4 spaces). I added a emacs configuration comment so anyone who opens the files with emacs will end up indenting with a tab character just so it stays consistent. FWIW rlm_ldap needs some love in other places, possibly a minor rewrite, formatting can be addressed then. Have fun, hope this helps ... John -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
Attached is a git format patch which adds support for storing clients in LDAP. The necessary schema can be found in doc/examples/389_ds_schema.ldif. This is schema ldif file suitable for use with 389-ds (the standard LDAP server shipped with Fedora and RHEL which over the years with different versions has been known under a variety of names, Netscape Directory Server, iPlanet, Sun Directory Server, Red Hat Directory Server, Fedora Directory server).
The patch was against the 2.1.10 branch. Here are a few quick notes.
Any thoughts on adding it to 2.1.10?
* Its had only light testing, but seems to work O.K. It should probably be tested in different with different combinations of client specification.
* I did add support for COA, but that's not tested.
<g> Sure.
* When I was looking at the schema I noticed the OID's which are being used (in each of the schema files I looked at) are not registered and do not belong to FreeRADIUS (they belong to the GNOME name space and I believe the reason for that is GNOME had a block of OID's and for expediency they were "borrowed"). I did not update the other ldap schema files in the patch, the new schema should be reviewed first. The new attributes and object classes should then be merged into the other schema files.
Yes.
* The code to parse a client IP address is now duplicated in three places in the server, in client.c when reading the clients file, in rlm_sql.c and rlm_ldap.c. The code should probably be refactored so there is a common subroutine to do this.
Yes. That's a low priority, however.
* The schema should be reviewed. One thing was immediately came to my mind was case sensitivity, right now the matching rules are case insenstive. Also the strings are defined to be ASCII (actually IA5). Perhaps the strings should be UTF-8 case sensitive. But that's less important than making sure the right attributes and object classes are defined and their naming makes sense.
I agree.
* The attribute names are hard coded in the source, but that's consistent with how the rest of rlm_ldap works, but that does mean you're tied to using the supplied schema.
Yes. Changing the attribute names is easy enough to do later.
* I followed the existing indentation (each indent level is a tab character) which I personally dislike (I would prefer to see an indent of 4 spaces). I added a emacs configuration comment so anyone who opens the files with emacs will end up indenting with a tab character just so it stays consistent. FWIW rlm_ldap needs some love in other places, possibly a minor rewrite, formatting can be addressed then.
rlm_ldap needs some work. So does rlm_sql. Oh well. Alan DeKok.
On 08/24/2010 10:18 AM, Alan DeKok wrote:
The patch was against the 2.1.10 branch. Here are a few quick notes.
Any thoughts on adding it to 2.1.10?
I think folks would appreciate the functionality in 2.1.10 so I would agree to adding it to 2.1.10. However I would argue that would be dependent on getting the schema reviewed first. Nothing worse than having a schema get out into the field, have folks start using it and then discover it needs to be modified. Does FreeRADIUS have a block of OID's? Are the client values case sensitive? (I know I could figure those questions out on my own but I'm a little time constrained at the moment). -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
I think folks would appreciate the functionality in 2.1.10 so I would agree to adding it to 2.1.10. However I would argue that would be dependent on getting the schema reviewed first. Nothing worse than having a schema get out into the field, have folks start using it and then discover it needs to be modified.
Yup. But I don't think many people are competent to review the schema. From what I know of LDAP, it looks reasonable.
Does FreeRADIUS have a block of OID's?
Yes. The 11344 private enterprise code has been assigned to FreeRADIUS.
Are the client values case sensitive?
The secret, nastype, nas password, and virtual server names are case sensitive. The other fields are used only for printing, not for lookups. So they can be case insensitive, as they don't matter.
(I know I could figure those questions out on my own but I'm a little time constrained at the moment).
I know the feeling. Alan DeKok.
On 08/24/2010 10:37 AM, Alan DeKok wrote:
John Dennis wrote:
I think folks would appreciate the functionality in 2.1.10 so I would agree to adding it to 2.1.10. However I would argue that would be dependent on getting the schema reviewed first. Nothing worse than having a schema get out into the field, have folks start using it and then discover it needs to be modified.
Yup. But I don't think many people are competent to review the schema. From what I know of LDAP, it looks reasonable.
Does FreeRADIUS have a block of OID's?
Yes. The 11344 private enterprise code has been assigned to FreeRADIUS.
Are the client values case sensitive?
The secret, nastype, nas password, and virtual server names are case sensitive. The other fields are used only for printing, not for lookups. So they can be case insensitive, as they don't matter.
O.K. I'll update the 389_ds_schema.ldif to use the FreeRADIUS oid's for *all* the attributes. Set the syntax to utf-8 and make the above values case sensitive, the other insensitive for the new client stuff. There are other radius attributes in the schema which have been there for a while, not sure where they originated. I wonder if they should also be reviewed to check if they should be IA5 or UTF-8 and their case sensitivity. I think you might have the best immediate understanding of how these attributes are getting used with RADIUS and if their definition is correct. For instance most of them are defined to be IA5 (1.3.6.1.4.1.1466.115.121.1.26). IA5 is almost equivalent to ASCII (see http://www.zytrax.com/tech/ia5.html). One would hope the days of IA5 are behind us. Then there are other attributes which are defined as IA5 strings which seems dubious to me, for example IdleTimeout and a couple of port specifications (should be integer?) and a number of attributes when appear to be booleans (but are defined as strings). Finally are all these attributes still in use or are they legacy cruft? -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On 24/8/2010 6:58 μμ, John Dennis wrote:
On 08/24/2010 10:37 AM, Alan DeKok wrote:
John Dennis wrote:
I think folks would appreciate the functionality in 2.1.10 so I would agree to adding it to 2.1.10. However I would argue that would be dependent on getting the schema reviewed first. Nothing worse than having a schema get out into the field, have folks start using it and then discover it needs to be modified.
Yup. But I don't think many people are competent to review the schema. From what I know of LDAP, it looks reasonable.
Does FreeRADIUS have a block of OID's?
Yes. The 11344 private enterprise code has been assigned to FreeRADIUS.
Are the client values case sensitive?
The secret, nastype, nas password, and virtual server names are case sensitive. The other fields are used only for printing, not for lookups. So they can be case insensitive, as they don't matter.
O.K. I'll update the 389_ds_schema.ldif to use the FreeRADIUS oid's for *all* the attributes. Set the syntax to utf-8 and make the above values case sensitive, the other insensitive for the new client stuff.
There are other radius attributes in the schema which have been there for a while, not sure where they originated. I wonder if they should also be reviewed to check if they should be IA5 or UTF-8 and their case sensitivity. I think you might have the best immediate understanding of how these attributes are getting used with RADIUS and if their definition is correct. For instance most of them are defined to be IA5 (1.3.6.1.4.1.1466.115.121.1.26). IA5 is almost equivalent to ASCII (see http://www.zytrax.com/tech/ia5.html). One would hope the days of IA5 are behind us. Then there are other attributes which are defined as IA5 strings which seems dubious to me, for example IdleTimeout and a couple of port specifications (should be integer?) and a number of attributes when appear to be booleans (but are defined as strings).
Finally are all these attributes still in use or are they legacy cruft?
All attribute values could use the syntax "<op> <value>" where <op> one of =,:=, += etc (it's been a while since i used it though, see ldap_pairget()). So it's probably a good idea to keep them that way.Why would you handle most RADIUS attribute values as UTF-8 instead of plain ASCII? -- Kostas Kalevras Network Operations Center, NTUA.GR http://kkalev.wordpress.com http://kkalev4economy.wordpress.com
On 08/25/2010 03:51 AM, Kostas Kalevras wrote:
All attribute values could use the syntax "<op> <value>" where<op> one of =,:=, += etc (it's been a while since i used it though, see ldap_pairget()). So it's probably a good idea to keep them that way.Why would you handle most RADIUS attribute values as UTF-8 instead of plain ASCII?
Internally most software is agnostic as to whether string data is ASCII or UTF-8 provided it handles the string as a whole unit and does not try to operate on individual characters or substrings. Not all attributes are appropriate candidates for i18n support, however those which are fundamentally names and descriptions would benefit. For example when I added client (e.g. NAS) support to rlm_ldap it seemed to me the client short name and description should support i18n. For the previously existing attributes in the schema I would imagine things the the GroupName, HuntGroupName, Prompt, UserCategory, ReplyMessage, etc. would be friendlier if you could specify these values in your native language. An open question is if internally FreeRADIUS does anything with these values other than copy them and compare them for equality, if that's the only operations then there shouldn't in theory be a problem. However even if there were internal problems with these values being encoded in UTF-8 that is an independent issue from whether the specification of a backend database schema which might be widely deployed should fundamentally prohibit the possibility of storing strings in a native language. Remember that ASCII is a proper subset of UTF-8 so if current practice remains storing only ASCII strings nothing would be affected (other than we've provided one part of the path for any future support of i18n without having to go back and modify your database). Does that make more sense? -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
Internally most software is agnostic as to whether string data is ASCII or UTF-8 provided it handles the string as a whole unit and does not try to operate on individual characters or substrings.
FYI: Pretty much all of the "readable content" RADIUS attributes are UTF-8. Any non-readable content attributes are opaque binary blobs.
Not all attributes are appropriate candidates for i18n support, however those which are fundamentally names and descriptions would benefit. For example when I added client (e.g. NAS) support to rlm_ldap it seemed to me the client short name and description should support i18n. For the previously existing attributes in the schema I would imagine things the the GroupName, HuntGroupName, Prompt, UserCategory, ReplyMessage, etc. would be friendlier if you could specify these values in your native language.
All of the "internal" FreeRADIUS attributes like "Group" or "Huntgroup" should be UTF-8.
An open question is if internally FreeRADIUS does anything with these values other than copy them and compare them for equality, if that's the only operations then there shouldn't in theory be a problem.
Pretty much, yes.
However even if there were internal problems with these values being encoded in UTF-8 that is an independent issue from whether the specification of a backend database schema which might be widely deployed should fundamentally prohibit the possibility of storing strings in a native language.
The server should be able to handle any printable string as UTF-8. Alan DeKok.
On 25/8/2010 3:32 μμ, John Dennis wrote:
On 08/25/2010 03:51 AM, Kostas Kalevras wrote:
All attribute values could use the syntax "<op> <value>" where<op> one of =,:=, += etc (it's been a while since i used it though, see ldap_pairget()). So it's probably a good idea to keep them that way.Why would you handle most RADIUS attribute values as UTF-8 instead of plain ASCII?
Internally most software is agnostic as to whether string data is ASCII or UTF-8 provided it handles the string as a whole unit and does not try to operate on individual characters or substrings. Not all attributes are appropriate candidates for i18n support, however those which are fundamentally names and descriptions would benefit. For example when I added client (e.g. NAS) support to rlm_ldap it seemed to me the client short name and description should support i18n. For the previously existing attributes in the schema I would imagine things the the GroupName, HuntGroupName, Prompt, UserCategory, ReplyMessage, etc. would be friendlier if you could specify these values in your native language.
An open question is if internally FreeRADIUS does anything with these values other than copy them and compare them for equality, if that's the only operations then there shouldn't in theory be a problem. However even if there were internal problems with these values being encoded in UTF-8 that is an independent issue from whether the specification of a backend database schema which might be widely deployed should fundamentally prohibit the possibility of storing strings in a native language. Remember that ASCII is a proper subset of UTF-8 so if current practice remains storing only ASCII strings nothing would be affected (other than we've provided one part of the path for any future support of i18n without having to go back and modify your database). Does that make more sense?
RADIUS attributes sent over the wire that are expected to contain a UTF-8 value (like Reply-Message) should be set as UTF-8 in the LDAP schema. Other attributes which are primarily used by freeradius internally (like huntgroupname or groupname) could be set to UTF-8 as long as freeradius is able to handle UTF-8 values. Alan could answer on the last one better. -- Kostas Kalevras Network Operations Center, NTUA.GR http://kkalev.wordpress.com http://kkalev4economy.wordpress.compname or
On 08/25/2010 08:41 AM, Kostas Kalevras wrote:
On 25/8/2010 3:32 μμ, John Dennis wrote:
On 08/25/2010 03:51 AM, Kostas Kalevras wrote:
All attribute values could use the syntax "<op> <value>" where<op> one of =,:=, += etc (it's been a while since i used it though, see ldap_pairget()). So it's probably a good idea to keep them that way.Why would you handle most RADIUS attribute values as UTF-8 instead of plain ASCII?
Internally most software is agnostic as to whether string data is ASCII or UTF-8 provided it handles the string as a whole unit and does not try to operate on individual characters or substrings. Not all attributes are appropriate candidates for i18n support, however those which are fundamentally names and descriptions would benefit. For example when I added client (e.g. NAS) support to rlm_ldap it seemed to me the client short name and description should support i18n. For the previously existing attributes in the schema I would imagine things the the GroupName, HuntGroupName, Prompt, UserCategory, ReplyMessage, etc. would be friendlier if you could specify these values in your native language.
An open question is if internally FreeRADIUS does anything with these values other than copy them and compare them for equality, if that's the only operations then there shouldn't in theory be a problem. However even if there were internal problems with these values being encoded in UTF-8 that is an independent issue from whether the specification of a backend database schema which might be widely deployed should fundamentally prohibit the possibility of storing strings in a native language. Remember that ASCII is a proper subset of UTF-8 so if current practice remains storing only ASCII strings nothing would be affected (other than we've provided one part of the path for any future support of i18n without having to go back and modify your database). Does that make more sense?
RADIUS attributes sent over the wire that are expected to contain a UTF-8 value (like Reply-Message) should be set as UTF-8 in the LDAP schema. Other attributes which are primarily used by freeradius internally (like huntgroupname or groupname) could be set to UTF-8 as long as freeradius is able to handle UTF-8 values. Alan could answer on the last one better.
O.K. so were all in agreement :-) Just to recap, the current LDAP schema has a number of these values specified to be IA5 rather than UTF-8 and all I was suggesting is that we fix what appears to have been a historical mistake. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Hi,
The patch was against the 2.1.10 branch. Here are a few quick notes.
Any thoughts on adding it to 2.1.10?
I think folks would appreciate the functionality in 2.1.10 so I would agree to adding it to 2.1.10. However I would argue that would be dependent on getting the schema reviewed first. Nothing worse than having a schema get out into the field, have folks start using it and then discover it needs to be modified.
Other folks who don't use ldap would possibly appreciate getting 2.1.10 soon - I for one am waiting eagerly for a released version with the MS-MPPE fixes for EAP-MSCHAPv2. Actually, since there was a "last call" for 2.1.10 more than two weeks ago, I went into hit-F5 mode, waiting for the release. Introducing new code with new features so late, plus delaying things with a pending schema review sounds a bit odd. I'd be in favour of pushing it into a 2.1.11 separately. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Stefan Winter wrote:
Other folks who don't use ldap would possibly appreciate getting 2.1.10 soon - I for one am waiting eagerly for a released version with the MS-MPPE fixes for EAP-MSCHAPv2. Actually, since there was a "last call" for 2.1.10 more than two weeks ago, I went into hit-F5 mode, waiting for the release.
OK.
Introducing new code with new features so late, plus delaying things with a pending schema review sounds a bit odd. I'd be in favour of pushing it into a 2.1.11 separately.
That's fine by me. Alan DeKok.
Am 20.08.2010 18:43, schrieb John Dennis:
Attached is a git format patch which adds support for storing clients in LDAP. The necessary schema can be found in doc/examples/389_ds_schema.ldif. This is schema ldif file suitable for use with 389-ds (the standard LDAP server shipped with Fedora and RHEL which over the years with different versions has been known under a variety of names, Netscape Directory Server, iPlanet, Sun Directory Server, Red Hat Directory Server, Fedora Directory server).
There seems to be a problem if you have more than one client in LDAP. perform_search() says: DEBUG(" [%s] got ambiguous search result (%d results)", inst->xlat_name, ldap_errno); clears the result and returns with RLM_MODULE_NOTFOUND if you have 0 or
1 entries in the result set.
Not sure what the consequences are if you just remove the >1 entries in the result set check in perform_search... Stephan
On 08/27/2010 06:48 AM, Stephan Jäger wrote:
Am 20.08.2010 18:43, schrieb John Dennis:
Attached is a git format patch which adds support for storing clients in LDAP. The necessary schema can be found in doc/examples/389_ds_schema.ldif. This is schema ldif file suitable for use with 389-ds (the standard LDAP server shipped with Fedora and RHEL which over the years with different versions has been known under a variety of names, Netscape Directory Server, iPlanet, Sun Directory Server, Red Hat Directory Server, Fedora Directory server).
There seems to be a problem if you have more than one client in LDAP.
perform_search() says:
DEBUG(" [%s] got ambiguous search result (%d results)", inst->xlat_name, ldap_errno);
clears the result and returns with RLM_MODULE_NOTFOUND if you have 0 or
1 entries in the result set.
Not sure what the consequences are if you just remove the>1 entries in the result set check in perform_search...
The callers of perform_search normally expect exactly one result because they are trying to find a specific entry. However that logic is really in the domain of the routine calling perform_search because only they know what they're looking for and the logic surrounding it. The search routine should just perform a search and not impose logic of it's own on the result. I imagine the reason why the search routine is enforcing the single result condition is because previously it was always the case 1 result was desired and it was easier to put the check in one place instead of after each call to perform_search. In our case we really do want multiple results, it's wrong for perform_search to tell us we don't know what we're looking for, it's job should be to do the search, period. There are two ways we can fix this. 1) We can add an extra parameter to perform_search which states how many results are expected, -1 would mean unbounded. This would eliminate needing to check the count every place perform_search was called. 2) We could remove the check from perform search and do the check after each call to perform search. I think option 1 would be cleaner. FWIW we really do want to perform the check for most callers of perform_search they do need to validate the count. I'll update the patch using option 1. Thanks for discovering this, as I said it was only lightly tested and I foolishly tested only with 1 client. John -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On 08/27/2010 11:16 AM, John Dennis wrote:
I'll update the patch using option 1.
Attached is an updated git patch. It's the same as the original patch except ldap_search() now takes an extra parameter specifying the expected number of entries. The patch was merged with the previous patch via git rebase interactive and squashing the two commits together. Once again, only light testing, sorry, I'm a little time constrained at my end. Please give it a whirl and let us know if you discover any issues. The patch does *not* address any of the schema updates previously discussed. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
Once again, only light testing, sorry, I'm a little time constrained at my end. Please give it a whirl and let us know if you discover any issues.
The patch does *not* address any of the schema updates previously discussed.
Thanks. We'll take a look at it for 2.1.11. Alan DeKok.
participants (5)
-
Alan DeKok -
John Dennis -
Kostas Kalevras -
Stefan Winter -
Stephan Jäger