[SSSD] Tool for querying SSSD database

Jakub Hrozek jhrozek at redhat.com
Wed Mar 27 08:38:10 UTC 2013


On Wed, Mar 27, 2013 at 01:45:29AM +0100, David Bambušek wrote:
> Dne 25.2.2013 11:50, Jakub Hrozek napsal(a):
> >On Mon, Feb 25, 2013 at 11:11:01AM +0100, David Bambušek wrote:
> >>Greetings,
> >>my name is David Bambusek, and I am working on an application , that will
> >>be used as a tool for querying SSSD database. I am curently a student of
> >>FIT VUT Brno and this is topic of my bachelor thesis. It will be a command
> >>line application able to query various types of data, that is stored in
> >>SSSD database. I made a web page, where I will add information about this
> >>application I named sss_query, so far, you can find there information about
> >>basic user interface ( www.bambusekd.cz/sss_query.html ).
> >>
> >>My project is on my Github account
> >>https://github.com/bambusekd/SSSD.git
> >>there I created branch sss_query, where I work on my application
> >>
> >>I will be glad for any advice, recommendation or comment to it.
> >>
> >>Thanks
> >>
> >>David Bambusek
> >Hi,
> >
> >I have some questions and comments related to design:
> >
> >1) I suggest to read the thread at:
> >https://lists.fedorahosted.org/pipermail/sssd-devel/2012-February/008712.html
> >if you haven't seen it already.
> >
> >2) Have you seen samba's wbinfo tool? Maybe in your thesis you could
> >compare the two.
> >
> >3) The list of objects to operate on is incomplete. You also need to
> >work with sudo rules, SSH hosts and I would also strongly suggest
> >including domains and subdomains. (for domains, include info like sysdb
> >domain version for instance). There should also be a way to perform
> >unkeyed search (=all objects of type X).
> >
> >4) Is the output always going to include all attributes or were you
> >going to have a "human readable" and "raw" output? What about group
> >memberships? Are there any plans to merge functionality with the
> >sss_groupshow tool ?
> >
> >5) There are a couple of tickets in the SSSD trac related to this
> >effort. Depending on the scope of your thesis you might want to assign
> >them to yourself.
> >
> >The related tickets are:
> >https://fedorahosted.org/sssd/ticket/1220
> >https://fedorahosted.org/sssd/ticket/1221
> >https://fedorahosted.org/sssd/ticket/1222
> >https://fedorahosted.org/sssd/ticket/1223
> >
> >Feel free to also create another ones.
> >
> >6) Please also include plans for unit tests in your design and
> >implementation.
> >_______________________________________________
> >sssd-devel mailing list
> >sssd-devel at lists.fedorahosted.org
> >https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> Hello,
> I would like to ask for a little help with tests for my application.
> I went through source codes of tests in /src/tests and have been
> little bit confused from them. So far, I have always made tests for
> applications in bash, where I was testing the application on correct
> outputs from given inputs, but as I saw, you use quite different
> approach in SSSD. Do I understand correctly, that you make test for
> every function that you write? Is there any documentation/tutorial
> on how to make tests for code zou write? Or could you push me
> forward little bit or give me piece of advice, so I would know how
> to make tests for my application?
> 
> Thank you very much in advance
> David Bambusek

The tests in src/tests are usually API tests (except for the latest
cmocka-based ones). That's one option -- if your tool has a number of
functions internally that walk the database and collect their contents,
you could write tests in C for those functions.

But then maybe instead of testing the functions there it might be better
to create a test in Python similar to src/tests/pyhbac-test.py that would
store an entity to cache using the pysss module (or calling the sss_ tools)
and then call your sss_query and assert that the object sss_query found
is the one you stored with the pysss module.

A test in bash might do as well as a last resort, but I personally find
any bash code larger than a couple of lines unreadable and hard to maintain.



More information about the sssd-devel mailing list