sssd-devel April 2010

sssd-devel@lists.fedorahosted.org

17 participants
63 discussions

[PATCH] Fix bad merge between sync sysdb and the sss_userdel patches
by Stephen Gallagher 12 Apr '10

12 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Completely my fault. I didn't pay enough attention when merging these. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDLeYACgkQeiVVYja6o6O4cwCfU25fAGiKqhZvf63HO2JyURUQ wbkAn2Yy3Hsm0qSS4ys5Fm5FqGLjeKio =2tyq -----END PGP SIGNATURE-----

2 2

[BRANCHING] Branching SSSD 1.2
by Stephen Gallagher 12 Apr '10

12 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As of right now, development for SSSD 1.2 and SSSD 1.3 has branched. Features currently slated for SSSD 1.2 (those related to completing integration with the forthcoming FreeIPA v2 server) should continue to work on the sssd-1-2 branch. Features for future functionality should continue on the master branch. It is important to note that this branch has occurred because we have pushed to the master branch a set of patches to convert the sysdb to synchronous operation for simplicity of use. Because of the inherent complexity in this, there is a chance that the master branch may be a bit unstable for the next week or two while we identify any issues with the conversion. The sssd-1-2 branch should remain fairly stable. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDH/YACgkQeiVVYja6o6OE7QCgkIZIDL5/8uEpWscBK3rIJ1Wg yjsAn0MBncvC1lbz/s7MbPXOg595WCT6 =zegx -----END PGP SIGNATURE-----

1 0

[PATCH] Support docdir and abs_builddir
by Stephen Gallagher 12 Apr '10

12 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Old versions of autoconf (before 2.60) did not include support for the docdir and abs_builddir variables. This patch emulates support for them. Fixes https://fedorahosted.org/sssd/ticket/422 - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAku9+9cACgkQeiVVYja6o6NWhwCgnzPiPds8WqDnFKTv9dG/mATS u5UAoK3F51osM9MJmDnFYz1JY0wt+Ihb =gkwc -----END PGP SIGNATURE-----

3 6

INI validation design page for review
by Dmitri Pal 09 Apr '10

09 Apr '10

Hi, Added the following page: https://fedorahosted.org/sssd/wiki/WikiPage/INIFileValidatorDesign This is significant effort, I should say... Will be quite a headache. I wonder is it really worth it at this point? IMO I would prefer switching to ELAPI and bringing it into a decent shape and then get back to this in half a year... -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

1 0

[Transifex] File submitted via email to SSSD | master
by admin＠transifex.net 08 Apr '10

08 Apr '10

Hello sssd, this is Transifex at http://www.transifex.net. The following attached files were submitted to SSSD | master by guidograzioli <guido.grazioli(a)gmail.com> Please, visit Transifex at http://www.transifex.net/projects/p/sssd/c/master/ in order to see the component page. Thank you, Transifex

2 2

SELinux login management
by Jakub Hrozek 08 Apr '10

08 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adds a new option -Z to sss_useradd and sss_usermod. This option allows user to specify the SELinux login context for the user. On deleting the user with sss_userdel, the login mapping is deleted, so subsequent adding of the same user would result in the default login context unless - -Z is specified again. MLS security is not supported as of this patch. Also adds explicit build dependency on libselinux-devel - it is dragged in by krb5-devel currently, but I think the dependency should be listed since we directly use functions from libselinux to set homedir contexts. Addresses: #230 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkuzLiMACgkQHsardTLnvCWgTQCg65NQNehKqYLiPjsCFs0kYLiU 4KYAoMcBB7/lAAkCblraMBpaZsGh1XzF =q2rI -----END PGP SIGNATURE-----

2 6

[PATCH] Refarray interface documentation
by Dmitri Pal 08 Apr '10

08 Apr '10

Hi, Added doxygen interface description to refarray. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

3 3

INI validation design thoughts
by Dmitri Pal 08 Apr '10

08 Apr '10

Hi, I was looking at the ideas that Steve vocalized yesterday for the INI validation. To recap: Consider using XML/XSLT/Relax NG/Schematron to do ini file validation. I did some research on the matter and here is what I am thinking. What we want to accomplish is the internal validation of the INI file when it is loaded. We do not want to fork a separate process that will validate the INI file. Though the suggested approach generally makes sense but there is no open source C implementation for the Schematron that I could find. And even if it exists it will take time to make sure it is a part of the distributions we care about. Libxml supports schema validation but I really do not see a big benefit in going this path. To validate an ini file the library (embeded into the application) would have to: 1) Read the schema file 2) Convert schema to the RelaxNG schema on the fly 3) Read the config file 4) Convert it to xml probably using XSLT 5) Use libxml to implement validation logic This just sounds a bit too heavy. I had in mind a more customized approach 1) Read schema file 2) Read config file 3) Validate The step 3 here is the core of the work but it is definitely comparable with the conversion work and validation logic in the XML case. The first approach at the point looks a bit too heavy both from application point of view and development point of view. Another point is that in the second approach we can do the work gradually and increase the complexity of the validation as we go. And do not forget that the option 1 is just schema validation without any conditions. I have some ideas about how we can use the conditions in the second approach more easily. Not to forget that first approach would require some time to get fluent with XSLT, RelaxNG and libxml - this would take some time while with the second approach the development can start immediately. Here is the design that I have in mind for the INI schema definition file and logic related to it. The INI file schema definition ini file will consist of description of the experted configuration optioins in the INI file. It will consist of the sections that describe keys in the ini files and sections that describe rules. We will skip rules for now and will talk about just the sections that define keys. I think that if we implement just that we will bring a lot of value. Any section in the schema definition file will have a unique name. This the name of the section not the name of the key. This is an important difference. Think about the name of the section as the name of the variable that holds an object that describes some key. Each key definition section would have the following possible attributes that describe the properties of the key and its value in the configuration file. Here is an example. Say we want to describe the key "provider" in the section "backend" of the INI file. Here how it might look like in the INI schema definition: [backendprovier] type = field <- Optional if omitted type "field" is assumed. Possible values: field, rule. Rule value not supported in v1 section = backend <- Optional, specifies what section the key belongs to. If omitted the "secref" key should be defined. See below. name = provider <- Required, must be a unique name within the section. required = yes <- Optional, if omitted "no" is assumed vtype = string <- Type of the value. Can be : int32, uint32, long32, ulong32, double, bool, list = no <- Optional, if omitted "no" is assumed, specifies if the value is the list or not sep = ,; <- Potential other symbols that can be used as list item separators - can be added later And so on... Other interesting keys that came to mind: min = 0 <- Min value for a numeric key max = 1000 <- Max value for a nemeric key Alternatively we can support (later) something like: ranges = 0, 10, 20, 30 < will mean that the value should be in range from 0 to 10 or between 20 and 30. Might come up with some better syntax... The following keys would be interesting too: depends = backendprovier, backendsomthingelse <- This means that the key becomes required if the key backendprovier or key backendsomthingelse is defined. Notice that "backendsomthingelse" is used as a reference to another section in the schema. So far all this can be handled by the INI parsing without modification. We some improvements and additions we can add something like this: depends = backendprovier[foo, bar, baz] <- That would mean that the key becomes required only in case the value of the backendprovier is foo, bar or baz. Another interesting key that we might want to define is: seclist seclist = yes <- Would mean that the value of the key specifies sections in the ini file. Can be used in the conjunction with "secprefix" secprefix = sometext <- Would mean that the name of the sections should be constructed by prepending this value Potentially we can also add "secprefixref" that will point to a key whose value should be added as prefix for the section names. Here is the example. The configuration like this: [backends] domain = foo.com be = bar, baz [foo.com/bar] one = 1 Will be described with schema definition like this: [backend_domains] section = backends name = domain required = yes vtype = string [backend_bs] section = backends name = domain required = yes seclist = yes <implies list=yes and vtype = string secprefixref = backend_domains [subsection_one] secref = backend_ds name = one vtype = int32 We can get more complex as we go and find use cases we need to cover. As we go we will also create best practices about creating your INI files. For example one of the things that IMO should be prohibited in the INI files at least for now is multiple dependency on presence or value. I mean things like: value of the key X should be present if the key Y is present and the key Z has value "abc". I envision the "rules" type section for dependencies like this. I think that complexity can be added later if ever needed. With the schema definition like this we would be able to validate the following things about configuration: 1) The value is present when it should 2) The value has expected type and range 3) The dependencies are correct I think that covers most of the issues we need to deal with in the INI files. Steve can we check that this grammar covers what we currently have in the sssd.ini? -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

5 17

[Transifex] File submitted via email to SSSD | master
by admin＠transifex.net 07 Apr '10

07 Apr '10

Hello sssd, this is Transifex at http://www.transifex.net. The following attached files were submitted to SSSD | master by dvd <dmi3652(a)gmail.com> Please, visit Transifex at http://www.transifex.net/projects/p/sssd/c/master/ in order to see the component page. Thank you, Transifex

2 1

Re: [SSSD] [PATCHES] INI meta data interface patches
by Dmitri Pal 07 Apr '10

07 Apr '10

Updated patch with the latest fix is attached. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel April 2010