Re: [DA][Fwd] LDAPS support (and some more stuff)
"scientica (GMail)" <[email protected]> Wed, 03 Aug 2005 15:32:16 +0200
| Newsgroups | gmane.network.directoryadmin |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------020109050005010806050505
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Manuel Amador (Rudd-O) wrote:
>>I've (tried) to make a short README.BRANCH and a TODO.BRANCH, the readme
>>file tries to explain what I've done. The TODO mentions a
>>"happens-at-random" bug, I think I have fixed it by adding a "sleep(1);"
>>before a "fclose(fd);"
>>
>>
>
>This is hackish dude! =)
>
>Try running under valgrind to discover mem corruption issues. I also
>had an account of someone who told me DA failed with a specific GCC
>compiler version and -O3 or -O2... Now I cannot remember what it was.
>
>
I wonder what really is the cause, since, the last "action" to the file
should have been completed when we reach fclose(), or fclose() should
fail with an error...
Maybe a bugzilla would be a GoodThing to setup?
>Or perhaps valgrind grinds DA to an unbearably slow state, which masks
>the bug.
>
>
possibly, since adding some slow down (sleep()) is what seems to fixed
it... (though I don't think I ever saw this with the vanilla 1.6 (didn't
use it for long before hacking it though ;)).
>AFAICR, DA is not using threads. I don't think it's even using gtk's
>mainloop integration for async fd operations.
>
>(which reminds me, has anyone ported this to gtk2? gtk1 it is beginning
>to look a little dated, and it pulls extra mostly unnecessary and old
>deps into distros)
>
>
Hmm, threads, I can't think of a reason why it should (except maybe
having the GUI handled in a sepparate thread - eg showing a progressbar
of long time operationg (like eg deletning 100+ users) ). I haven't read
up on the internals of gtk I must admin (only read what I had to know to
beable to implement the changes).
Gtk? Not that I'm aware of... wonder how much work it'd be
porting/uppgrading to gtk2 - I suspect it wont be as easy as changing a
few "old function calls" to "new function calls", but from what I can
tell gtk1 is becoming deprecated by time, also gtk2 seems to allow more
"things" (or people just lay down more time on estetics with gtk2).
Anyway, maybe we should move to gtk2 and make DA use that
manloop-integration-thingy?
>> - though, I just suspect that somehow fixed it
>>(haven't had any freezes since I added that line).
>>I would like to force everyone that even thinks about compiling this
>>version to read the README.BRANCH, especially the "Misc" section, where
>>it mentions something about the config file format-backwards
>>compabillity beeing breaked with this branch.
>>
>>
>Can the cfg file compat be preserved?
>The second best option would be to program a migration algo.
>
>
Sure it would be possible, but, imo, would be adding too much complexity
to add it to load_prefs() (thus asking for Muphy to come over). Maybe
the config format should be revised all together? (and then
writing/scripting a small conversion util would fix the config).
Everything seems to go xml nowdays, but I think that would be
ineffective, _if_ the cfg file is _only_ ment to ever store _connection
profiles and nothing else_ - but if plans are to move more config items
to the config file I think xml should be considered (I haven't checked
out libxml but I think it wouldn't be that hard to code a simple parser
(using libxml, libxml2 or so - most modern distros should already
provide them - given the wide spread use of xml) and write a simple DTD
(should enable some degree of format-versioning (eg like the xhtml1.0
and xhtml1.1 DTDs, but not that big ;) )).
I belive the advantages of rewriting the cfg file to an xml format would
be (but not really limited to):
1) That it's a little more future compatible (eg new config items could
be added without affecting other items (the curent formats would require
revising the format and add the extra code, and for compabillity even
more code would be required), and unset values could be defaulted
(and/or read from some "top level" config (eg put in /etc) ) ).
2) It would be relativly easy to store/add more users settings in the
config file, and should more connection methods be added a greater
degree of backwards compabillity should be "built-in" and say a new
conneciton method needs some extra value - adding an extra node or
attribute to the xml-tags/elemetns should be quite painless, and it
[sw]ouldn't confuse the config loader (as it would still read, let's say
<conection method="foobar" foobar_option="thingy"/>, and if "foobar" is
unknown it should (if we're not lazy and writning good code;) should
warn the user about it and disable the profile (still keeping it as is
with out corrupting it, yet allowing the user to modify it (possibly
truncating 'unkown' sub-tags or attributes)) ) or if the attribute
foobar_option is unknown it [sw]ouldn't affect the parser - it might be
an override of some default for "foobar" which isn't supported in older
versions, the "old" version [sc]ould ask/warn the user if (s)he wants to
continue connecting with the profile (ignoring the 'unknown' options) or
abort.
3) with a changed format one should then change the file name to
profile.xml or config.xml, and possibly add a simple
if(file_exists(configdir+"/profile"))
then
show_nice_messagebox("warning the user about the new config format
and asking the user to read the section in the docs that shows how to
uppgrade the config file, and ask the user if he want's to continue (to
the \"first time wizard\") or exit (and read the docs)")
fi
that way, in a "sane" way break backwards compabillity with the tradeof
a better and more "stable format" (well, imo at least)
4) I think it would simplify the reading and saving functions (well,
actually, maybe not, since I don't know how much functions libxml (or
equal) provies and how much must be coded, but those functions wouldn't
be in the load/save functions but avalible for all the app - in case we
would decide to sue xml elsewhere too (maybe read/save the user/group
list as xml or import from some xml format,etc,etc)). Anyway, the config
format would be more human friendly, imho, - eg compare
"FoozBar|1|0|...|fieldN" with '<connection title="FoozBar"
enableMcGuffin="1" connect_readonly="0"/>'
Generally I'm in favour of backwards compabillity (hey I think the (now
almost forgottne) A20-enable-stuff is a good thing to keep - what if
want to run a historical pre-GUI-bloat OS ;), but I think breaking it
can be justified by a better tradeof (and or burrying a dead-end design
choice). And I think the current profile format got many
restrictions/limitations, but for the time beeing, given that the only
user pref stored in that way is profiles it's enought to get the job
done without too much overhead (making it xml but still only intending
to save profiles would give a too high "overhead:data" ratio imo).
What are your oppinions about rewriting the whole config interface all
together? I think we could get far by changing to a xml based config,
rewriting the code from gtk1 to gtk2. And various other additions (I
think it might even be possible to assign custom "templates" to the
connection profiles, which could be defined in the config or "generic" -
"templates" as suggested in one of Neil Schneider's mail in the "Object
Class" disussion on this list.)
eg:
[...]
<!-- // I think prefixing "built in" templates with a dot (.) would be a
good solution (and disallowing any template name/id to begin with a dot
to void the risc of users confusing everyone and the parser/prefs_loader
(which then could assume that any templte that begins with '.' is to be
searched for in the built-ins and if not found it's a typo somehow) :) -->
<connections>
<connection title="My LDAP Server" dn="cn=Manager,dc=corp,dc=com"
template=".some_built_in_template">
<connection title="My LDAP Server" dn="cn=Manager,dc=corp,dc=com"
template="corp_template">
</connections>
<templates>
<template id="corp_template">
<object_class name="top"/>
<object_class name="corpAccount" description="Our custom account
schema" file="/path/to/schema"/>
</template>
</templates>
[...]
(note: this is just brain storming (hurricane, even) so I have no idea
how to handle the managment of the data, maybe adding more depth to the
templates and then have the 'input-dialog' be rendered in some way (eg
reading all fields, printing an label with the title and an input box
for each field), and the "built-in" templates could have "nicer"
'input-dialogs' ). Or letting the input-dialog box renderer (somehow)
get it's list/array of elements (and their type) from the shema file --
I'm not that keen on the schema format but guess it mihgt be best to
read the input's from it right? (the schema specifies the data type of
the field/class (classes could have the renderer output a pane for it
while putting the 'rest' in some "misc" pane) doesn't it?).
I could start on a branch to make some test implemenation of an xml
based config - if you think it's worth the time to give xml a try.
Did you follow my thouhts or did the wind threw you off (or me,
depending on from where we're looking :)? Feel free to ask me to
elaborate/simplify any part or all of it.
>>Any comments or questions are welcome. I belive that this branch is not
>>yet "production stable/ready", since it's not been fully tested and
>>since it breaks backwards compabillity with the configuration file
>>"~/.directory_administrator/profile".
>>
>>
>these profile routines are the dumbest dumbest ever routines I have ever
>written. Not to mention that this was what I think my first program in
>C was. Of course I found glib and gtk great and easy to use, but
>finally grew up and now I'm sold to pygtk.
>
>
They're not bad at least they work and they make a good starting point -
things can only get better, eh? ;)
>>Also, I'd really like to hear your comments on the debug macros (and the
>>add of --enable-debug which defines DEBUG so we can do things like
>>"#ifdef DEBUG", the DBG_PRINT and DBG_PRINT_DM are only printing debug
>>data when DEBUG is defined, thus when configure was run with
>>--enable-debug). And I've not done any specific tests with --disable-ldaps.
>>
>>oh, I just remembered, I've not added my self to the CREDITS file...
>>
>>
>by all means, do!
>
>
I will the next time, this wont be the last thing you see from me
[insert "Devil $etag - Evil Lughter Number 3.ogg"] ;)
btw, how do I check out the dir-admin svn? (I can't seem to get it
right, I'm thinking about forward patching the branch to 1.7)
Cheers
Fredrik
--
After all, if you are in school to study computer science, then a
professor saying:
"use this proprietary software to learn computer science" is the
same as English professor handing you a copy of Shakespeare
and saying:
"use this book to learn Shakespeare without opening the book itself."
-- Bradley Kuhn
--------------020109050005010806050505
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Manuel Amador (Rudd-O) wrote:
<blockquote cite="[email protected]" type="cite">
<blockquote type="cite">
<pre wrap="">I've (tried) to make a short README.BRANCH and a TODO.BRANCH, the readme
file tries to explain what I've done. The TODO mentions a
"happens-at-random" bug, I think I have fixed it by adding a "sleep(1);"
before a "fclose(fd);"
</pre>
</blockquote>
<pre wrap=""><!---->
This is hackish dude! =)
Try running under valgrind to discover mem corruption issues. I also
had an account of someone who told me DA failed with a specific GCC
compiler version and -O3 or -O2... Now I cannot remember what it was.
</pre>
</blockquote>
I wonder what really is the cause, since, the last "action" to the file
should have been completed when we reach fclose(), or fclose() should
fail with an error...<br>
Maybe a bugzilla would be a GoodThing to setup?<br>
<blockquote cite="[email protected]" type="cite">
<pre wrap="">Or perhaps valgrind grinds DA to an unbearably slow state, which masks
the bug.
</pre>
</blockquote>
possibly, since adding some slow down (sleep()) is what seems to fixed
it... (though I don't think I ever saw this with the vanilla 1.6
(didn't use it for long before hacking it though ;)).<br>
<blockquote cite="[email protected]" type="cite">
<pre wrap="">AFAICR, DA is not using threads. I don't think it's even using gtk's
mainloop integration for async fd operations.
(which reminds me, has anyone ported this to gtk2? gtk1 it is beginning
to look a little dated, and it pulls extra mostly unnecessary and old
deps into distros)
</pre>
</blockquote>
Hmm, threads, I can't think of a reason why it should (except maybe
having the GUI handled in a sepparate thread - eg showing a progressbar
of long time operationg (like eg deletning 100+ users) ). I haven't
read up on the internals of gtk I must admin (only read what I had to
know to beable to implement the changes).<br>
Gtk? Not that I'm aware of... wonder how much work it'd be
porting/uppgrading to gtk2 - I suspect it wont be as easy as changing a
few "old function calls" to "new function calls", but from what I can
tell gtk1 is becoming deprecated by time, also gtk2 seems to allow more
"things" (or people just lay down more time on estetics with gtk2).
Anyway, maybe we should move to gtk2 and make DA use that
manloop-integration-thingy?<br>
<blockquote cite="[email protected]" type="cite">
<blockquote type="cite">
<pre wrap=""> - though, I just suspect that somehow fixed it
(haven't had any freezes since I added that line).
I would like to force everyone that even thinks about compiling this
version to read the README.BRANCH, especially the "Misc" section, where
it mentions something about the config file format-backwards
compabillity beeing breaked with this branch.
</pre>
</blockquote>
<pre wrap="">Can the cfg file compat be preserved?
The second best option would be to program a migration algo.
</pre>
</blockquote>
Sure it would be possible, but, imo, would be adding too much
complexity to add it to load_prefs() (thus asking for Muphy to come
over). Maybe the config format should be revised all together? (and
then writing/scripting a small conversion util would fix the config).<br>
Everything seems to go xml nowdays, but I think that would be
ineffective, _if_ the cfg file is _only_ ment to ever store _connection
profiles and nothing else_ - but if plans are to move more config items
to the config file I think xml should be considered (I haven't checked
out libxml but I think it wouldn't be that hard to code a simple parser
(using libxml, libxml2 or so - most modern distros should already
provide them - given the wide spread use of xml) and write a simple DTD
(should enable some degree of format-versioning (eg like the xhtml1.0
and xhtml1.1 DTDs, but not that big ;) )).<br>
I belive the advantages of rewriting the cfg file to an xml format
would be (but not really limited to):<br>
1) That it's a little more future compatible (eg new config items could
be added without affecting other items (the curent formats would
require revising the format and add the extra code, and for
compabillity even more code would be required), and unset values could
be defaulted (and/or read from some "top level" config (eg put in /etc)
) ).<br>
2) It would be relativly easy to store/add more users settings in the
config file, and should more connection methods be added a greater
degree of backwards compabillity should be "built-in" and say a new
conneciton method needs some extra value - adding an extra node or
attribute to the xml-tags/elemetns should be quite painless, and it
[sw]ouldn't confuse the config loader (as it would still read, let's
say <conection method="foobar" foobar_option="thingy"/>, and if
"foobar" is unknown it should (if we're not lazy and writning good
code;) should warn the user about it and disable the profile (still
keeping it as is with out corrupting it, yet allowing the user to
modify it (possibly truncating 'unkown' sub-tags or attributes)) ) or
if the attribute foobar_option is unknown it [sw]ouldn't affect the
parser - it might be an override of some default for "foobar" which
isn't supported in older versions, the "old" version [sc]ould ask/warn
the user if (s)he wants to continue connecting with the profile
(ignoring the 'unknown' options) or abort.<br>
3) with a changed format one should then change the file name to
profile.xml or config.xml, and possibly add a simple<br>
<tt>if(file_exists(configdir+"/profile"))<br>
then<br>
show_nice_messagebox("warning the user about the new config format
and asking the user to read the section in the docs that shows how to
uppgrade the config file, and ask the user if he want's to continue (to
the \"first time wizard\") or exit (and read the docs)")<br>
fi<br>
</tt>that way, in a "sane" way break backwards compabillity with the
tradeof a better and more "stable format" (well, imo at least)<br>
4) I think it would simplify the reading and saving functions (well,
actually, maybe not, since I don't know how much functions libxml (or
equal) provies and how much must be coded, but those functions wouldn't
be in the load/save functions but avalible for all the app - in case we
would decide to sue xml elsewhere too (maybe read/save the user/group
list as xml or import from some xml format,etc,etc)). Anyway, the
config format would be more human friendly, imho, - eg compare
"FoozBar|1|0|...|fieldN" with '<connection title="FoozBar"
enableMcGuffin="1" connect_readonly="0"/>'<br>
<br>
Generally I'm in favour of backwards compabillity (hey I think the (now
almost forgottne) A20-enable-stuff is a good thing to keep - what if
want to run a historical pre-GUI-bloat OS ;), but I think breaking it
can be justified by a better tradeof (and or burrying a dead-end design
choice). And I think the current profile format got many
restrictions/limitations, but for the time beeing, given that the only
user pref stored in that way is profiles it's enought to get the job
done without too much overhead (making it xml but still only intending
to save profiles would give a too high "overhead:data" ratio imo).<br>
What are your oppinions about rewriting the whole config interface all
together? I think we could get far by changing to a xml based config,
rewriting the code from gtk1 to gtk2. And various other additions (I
think it might even be possible to assign custom "templates" to the
connection profiles, which could be defined in the config or "generic"
- "templates" as suggested in one of Neil Schneider's mail in the
"Object Class" disussion on this list.)<br>
eg: <br>
[...]<br>
<!-- // I think prefixing "built in" templates with a dot (.) would
be a good solution (and disallowing any template name/id to begin with
a dot to void the risc of users confusing everyone and the
parser/prefs_loader (which then could assume that any templte that
begins with '.' is to be searched for in the built-ins and if not found
it's a typo somehow) :) --><br>
<connections><br>
<connection title="My LDAP Server"
dn="cn=Manager,dc=corp,dc=com" template=".some_built_in_template"><br>
<connection title="My LDAP Server"
dn="cn=Manager,dc=corp,dc=com" template="corp_template"><br>
</connections><br>
<templates><br>
<template id="corp_template"><br>
<object_class name="top"/><br>
<object_class name="corpAccount" description="Our custom
account schema" file="/path/to/schema"/><br>
</template><br>
</templates><br>
[...]<br>
(note: this is just brain storming (hurricane, even) so I have no idea
how to handle the managment of the data, maybe adding more depth to the
templates and then have the 'input-dialog' be rendered in some way (eg
reading all fields, printing an label with the title and an input box
for each field), and the "built-in" templates could have "nicer"
'input-dialogs' ). Or letting the input-dialog box renderer (somehow)
get it's list/array of elements (and their type) from the shema file --
I'm not that keen on the schema format but guess it mihgt be best to
read the input's from it right? (the schema specifies the data type of
the field/class (classes could have the renderer output a pane for it
while putting the 'rest' in some "misc" pane) doesn't it?).<br>
I could start on a branch to make some test implemenation of an xml
based config - if you think it's worth the time to give xml a try.<br>
<br>
Did you follow my thouhts or did the wind threw you off (or me,
depending on from where we're looking :)? Feel free to ask me to
elaborate/simplify any part or all of it.<br>
<blockquote cite="[email protected]" type="cite">
<blockquote type="cite">
<pre wrap="">Any comments or questions are welcome. I belive that this branch is not
yet "production stable/ready", since it's not been fully tested and
since it breaks backwards compabillity with the configuration file
"~/.directory_administrator/profile".
</pre>
</blockquote>
<pre wrap=""><!---->these profile routines are the dumbest dumbest ever routines I have ever
written. Not to mention that this was what I think my first program in
C was. Of course I found glib and gtk great and easy to use, but
finally grew up and now I'm sold to pygtk.
</pre>
</blockquote>
They're not bad at least they work and they make a good starting point
- things can only get better, eh? ;)<br>
<blockquote cite="[email protected]" type="cite">
<blockquote type="cite">
<pre wrap="">Also, I'd really like to hear your comments on the debug macros (and the
add of --enable-debug which defines DEBUG so we can do things like
"#ifdef DEBUG", the DBG_PRINT and DBG_PRINT_DM are only printing debug
data when DEBUG is defined, thus when configure was run with
--enable-debug). And I've not done any specific tests with --disable-ldaps.
oh, I just remembered, I've not added my self to the CREDITS file...
</pre>
</blockquote>
<pre wrap=""><!---->by all means, do!
</pre>
</blockquote>
I will the next time, this wont be the last thing you see from me
[insert "Devil $etag - Evil Lughter Number 3.ogg"] ;)<br>
<br>
btw, how do I check out the dir-admin svn? (I can't seem to get it
right, I'm thinking about forward patching the branch to 1.7)<br>
<br>
Cheers<br>
Fredrik<br>
<br>
<pre class="moz-signature" cols="72">--
After all, if you are in school to study computer science, then a
professor saying:
"use this proprietary software to learn computer science" is the
same as English professor handing you a copy of Shakespeare
and saying:
"use this book to learn Shakespeare without opening the book itself."
-- Bradley Kuhn
</pre>
</body>
</html>
--------------020109050005010806050505--