[BRANCHING] Branching SSSD 1.2
by Stephen Gallagher
-----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-----
14 years
[PATCH] Support docdir and abs_builddir
by Stephen Gallagher
-----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-----
14 years
SELinux login management
by Jakub Hrozek
-----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-----
14 years
INI validation design thoughts
by Dmitri Pal
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/
14 years
