[Luma-devel] Re: [Luma-users] New version for testing

[Wido D. <wi...@gm...>]

On Thursday 15 July 2004 15:27, Nathan Benson wrote:
> so, along those lines i have a few suggestions that may/may not be of
> any use (or want for that matter) for Luma's continued development:
>
> 1. next available GID (to compliment the next UID)
That's possible. Altough it would not be as easy to use, compared to the 
normal group dialog. Maybe other people on the list could comment about this.


> 2. like your drop down for the password hash choices, maybe
>    in a similar fashion adding a button for find next UID/GID.
>
> 	- example, i created a "Unix Account" template using the
> 	  template plugin.   then i head over to the Browser plugin
> 	  and right click to bring up the "Add Item -> Unix Account".
> 	  it then pops up the template for me to fill out just like
> 	  it should.  it's here when i choose to modify the uidNumber
> 	  or gidNumber that the extra "Next Free" button would be
> 	  very handy.  i could always go to the Usermanagment plugin
> 	  first, get the next UID (and hopefully GID) and go back. but,
> 	  i don't want to run the risk of someone taking the UID/GID
> 	  before i finish, etc.
I have tought about that too, but decided to do it later. The problem is that 
the codebase for the handling of this widget is already quite complex and i 
wanted to change it fundamentally in the future. 
I'm planning to use the PyKDE bindings and use the html engine for rendering 
the data. This way we would gain more speed, it would look better and 
additional features would be easier to implement. For example the user can 
define default values for editing attributes.


> 3. adding an account lock/unlock to the password hash choices
>
> 	- this would allow for an account to be locked out, without
> 	  having to change the password or delete the account right
> 	  away.
>
> 	- i figured a ! could be inserted at the beginning of
> 	  the password string if it's encrypted:
>
> 		{MD5}!CY9rzUYh03PK3k6DJie09g==
For disabling the account, LDAP has the shadowExpire attribute. If you set it 
to a date in the past, the user won't be able to login. The only problem is, 
that it only works with users who belong to the shadowAccount objectClass. 
There are methods to realize this, but this is the only standard method.
Perhaps I could add a 'Disable account' button or something like that. I'll 
have a look on the WWW and try to find some references on this subject.


> 	- if the hash is cleartext (why?) it would have to be
> 	  a little more creative since inserting the ! is more
> 	  like security through obscurity.  maybe something
> 	  along these lines:
>
> 		{!cleartext}test
>
> 			or
>
> 		{LUMARULES}test
This way the user is able to use his own hashes which are not implemented in 
Luma. It's the only reason why it's there ;)


> that's all if have for right now (barring your threading support
> in upcoming releases), i hope you find it of some use.
Threading for LDAP queries is already implemented. It should be in the latest 
snapshot I have provided on my personal webspace.

> keep up the good work, Luma is really looking good!
Thanks, I'll do my best to improve Luma much more :)

By the way, how are your experiences with the latest version and SASL 
authentification? How does it work? Are your problems only releated to the 
usermanagement and addressbook plugin?

mfg.
  Wido