gqclient-discuss Mailing List for GQ LDAP client

On Sat, 15 Jul 2017, Bert Vermeulen wrote:

> This project was abandoned 10+ years ago, wouldn't expect it to work due 
> to bit rot etc.

Rats...  I was using it about 5 years ago (on FreeBSD) and it was really 
neat!  I might take a look at it if I get enthusiastic enough.

Thanks.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

On 07/15/2017 09:16 AM, Dave Horsfall wrote:
> GQ 1.2.3 on MacOS Sierra, installed as a port.
> 
> Does this actually work?  I cannot get a simple bind to work with a remote
> OpenLDAP server without it seeming to hang and then crashing (no core
> dump).

Dave,

This project was abandoned 10+ years ago, wouldn't expect it to work due to 
bit rot etc.


-- 
Bert Vermeulen
be...@bi...

GQ 1.2.3 on MacOS Sierra, installed as a port.

Does this actually work?  I cannot get a simple bind to work with a remote 
OpenLDAP server without it seeming to hang and then crashing (no core 
dump).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

Looking at the activity level of this list, the version numbers and 
commit dates and comparing them to what is currently being maintained in 
the Fedora repo, I'd say this project has moved.

"yum info gq" on a Fedora system turns up gq-1.3.4 and lists 
http://www.gq-project.org/ as the homepage for this project now, not 
SF.net, but that URL (and the alternate one I've seen listed at 
http://biot.com/gq/ , which currently just points at the one above) only 
produce a webpage that says "It works!". The page source provides no 
hints, either. GQ is not in the repos for SL or RHEL from what I can tell.


I found these in the Fedora 14 tree (yes, f13 packages in f14 -- this 
represents a snapshot of packages before the major changes of f15):

Source:	gq-1.3.4-9.fc13.src.rpm
( 
http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/14/Everything/source/SRPMS/gq-1.3.4-9.fc13.src.rpm 
)

x86_64:	gq-1.3.4-9.fc13.x86_64.rpm
( 
http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/14/Everything/x86_64/os/Packages/gq-1.3.4-9.fc13.x86_64.rpm 
)

i686:	gq-1.3.4-9.fc13.i686.rpm
( 
http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/14/Everything/i386/os/Packages/gq-1.3.4-9.fc13.i686.rpm 
)


... and these in the f15 repo (rebuilds after the systemd revolution and 
other core changes to the Fedora architecture that are taking place):

Source:	gq-1.3.4-10.fc15.src.rpm
( 
http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/15/Everything/source/SRPMS/gq-1.3.4-10.fc15.src.rpm 
)

x86_64:	gq-1.3.4-10.fc15.x86_64.rpm
( 
http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/15/Everything/x86_64/os/Packages/gq-1.3.4-10.fc15.x86_64.rpm 
)

i686:	gq-1.3.4-10.fc15.i686.rpm
( 
http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/15/Everything/i386/os/Packages/gq-1.3.4-10.fc15.i686.rpm 
)

There was no reference to GQ in the EPEL repo which covers extras for 
RHEL, Scientific Linux and CentOS -- but that they build for Fedora is a 
good indication that building for the others should work fine (maybe 
some tweaks or weird deps -- I'm about to find out).

Please note that the above repos are mirrors hosted near me. If they 
don't work for you check http://mirrors.fedoraproject.org/ for another 
location.

Here in the SF.net repo the highest version is 1.2.3 dated 2008-01-08... 
so obviously this is stale. But where in the world did Fedora get a hold 
of 1.3.4 if the upstream project is fried?

I haven't been around Debian land for a long time, but I'm almost 
certain you could find similar packages on that side if you're running 
Ubuntu, Debian, or whatever.

Fedora SRPM build directories only contain pristine upstream sources -- 
which is great for situations like this. Any Fedora-specific patches, 
scripts, whatever are in the base directory away from the build source, 
so building for any system (Slackware?) should be pretty easy from 
Fedora packages.

Hope this helps.

-Iwao

I can't find any documentation; in particular I'm looking for how I get gq
to authenticate to my ldap server so it has permission to modify things

Given the activity level I see in this mailing list archive, should I also
be asking what people are using instead of GQ?  Or is GQ still a good way
to maintain user and group information for a small single-sign-on system?
--
David Dyer-Bennet, dd...@dd...; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info



-- 
David Dyer-Bennet, dd...@dd...; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

Nigel Sa wants you to use Dropbox to sync and share files online and across computers.

Get started here: http://www.dropbox.com/link/20.Wsph0SQvPi/NjQzNzIxOTc5Nw

- The Dropbox Team

____________________________________________________ 
To stop receiving invites from Dropbox, please go to http://www.dropbox.com/bl/d0ad1e33c04b/gqclient-discuss%40lists.sourceforge.net

On 07/21/2008 02:55:23 AM, Sven Herzberg wrote:
> Pawel,
> 
> did you manage to test this?

Hm, I wasn't sure how to get this revision (is it on trunk?)

What I tried was 1.3.4 as distributed with F-9 and many of the previously  
observed problems disappeared. There is some bad interaction with keyring  
manager. It says that gq wants the keyring unlocked (although I had the  
keyring unlocked already). I typed the keyring password but I kept  
getting a message that the keyring has to be unlocked. I gave up after  
three(?) attempts and pressed Cancel - and suddenly gq managed to log in  
to LDAP server! Strange.

Paweł

> Am Dienstag, den 22.01.2008, 15:42 +0100 schrieb Sven Herzberg:
> > Hi Pawel,
> >
> > Am Mittwoch, den 09.01.2008, 18:14 +0100 schrieb Pawel Salek:
> > > I see some glitches with 1.3.3 already, the theme apparently cannot  
> find
> > > the ldap-person icon for some reason. I will investigate first and  
> write
> > > more thorough report later. /Paweł
> >
> > I just committed a patch to trunk that should fix this. Can you please
> > try revision 1163 and tell me if it works?
> >
> > Regards,
> >   Sven
> >
> >
> >  
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Gqclient-discuss mailing list
> > Gqc...@li...
> > https://lists.sourceforge.net/lists/listinfo/gqclient-discuss
> 

Davor, stack traces are a lot easier to read, than strace output; can
you provide proper information?

Regards,
  Sven

Am Donnerstag, den 24.07.2008, 15:43 +0200 schrieb Davor Ocelic:
> On Mon, 21 Jul 2008 02:28:01 +0200
> Sven Herzberg <her...@gn...> wrote:
> 
> > Davor,
> > 
> > did you do any further testing?
> 
> Just now I tried to compile new gq from SVN trunk and connect
> to the server, but the following happens:
> 
> 1) I edit default "localhost" entry to define Bind DN (I set it
>   to cn=admin,dc=mydc,dc=hr)
> 
> 2) I go to Browse tab and clicking the server results in 100% CPU
>   usage and Gq hangs.
> 
> Here's the output from strace which just keeps repeating itself
> indefinitely and which causes Gq to hang in a loop:
> 
> 
> connect(5, {sa_family=AF_FILE, path="/tmp/keyring-Zi2ZSe/socket"}, 110)
> = 0 write(5, "\0", 1)                       = 1
> write(5,
> "\0\0\0\n\0\0\0\2gq\0\0\0}\0\0\0\v\0\0\0\1\0\0\0\4\0\0\0\4user\0\0\0\0\0\0\0\32cn=admin,dc=spinlock,dc=hr\0\0\0\6server\0\0\0\0\0\0\0\tlocalhost\0\0\0\4port\0\0\0\1\0\0\1\205\0\0\0\10protocol\0\0\0\0\0\0\0\4ldap",
> 135) = 135 read(5, "\0\0\0\217", 4)                = 4 read(5,
> "\0\0\0\0\0\0\0\5login\0\0\0\1\0\0\0\5admin\0\0\0\4\0\0\0\4user\0\0\0\0\0\0\0\32cn=admin,dc=spinlock,dc=hr\0\0\0\6server\0\0\0\0\0\0\0\tlocalhost\0\0\0\4port\0\0\0\1\0\0\1\205\0\0\0\10protocol\0\0\0\0\0\0\0\4ldap",
> 139) = 139 close(5)                                = 0
> munlock(0xf7c04000, 16384)              = 0 munmap(0xf7c04000,
> 16384)               = 0 time(NULL)                              =
> 1216906861 write(4,
> "0+\2\1\7`&\2\1\2\4\32cn=admin,dc=spinlock,dc=hr\200\5admin", 45) = 45
> poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP, revents=POLLIN}],
> 1, -1) = 1 read(4, "0E\2\1\7a@\n", 8)              = 8 read(4,
> "\1\2\4\0\0049historical protocol version requested, use LDAPv3
> instead", 63) = 63 time(NULL)                              = 1216906861
> socket(PF_FILE, SOCK_STREAM, 0)         = 5 fcntl64(5, F_SETFD,
> FD_CLOEXEC)         = 0
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Gqclient-discuss mailing list
> Gqc...@li...
> https://lists.sourceforge.net/lists/listinfo/gqclient-discuss

On Mon, 21 Jul 2008 02:28:01 +0200
Sven Herzberg <her...@gn...> wrote:

> Davor,
> 
> did you do any further testing?

Just now I tried to compile new gq from SVN trunk and connect
to the server, but the following happens:

1) I edit default "localhost" entry to define Bind DN (I set it
  to cn=admin,dc=mydc,dc=hr)

2) I go to Browse tab and clicking the server results in 100% CPU
  usage and Gq hangs.

Here's the output from strace which just keeps repeating itself
indefinitely and which causes Gq to hang in a loop:


connect(5, {sa_family=AF_FILE, path="/tmp/keyring-Zi2ZSe/socket"}, 110)
= 0 write(5, "\0", 1)                       = 1
write(5,
"\0\0\0\n\0\0\0\2gq\0\0\0}\0\0\0\v\0\0\0\1\0\0\0\4\0\0\0\4user\0\0\0\0\0\0\0\32cn=admin,dc=spinlock,dc=hr\0\0\0\6server\0\0\0\0\0\0\0\tlocalhost\0\0\0\4port\0\0\0\1\0\0\1\205\0\0\0\10protocol\0\0\0\0\0\0\0\4ldap",
135) = 135 read(5, "\0\0\0\217", 4)                = 4 read(5,
"\0\0\0\0\0\0\0\5login\0\0\0\1\0\0\0\5admin\0\0\0\4\0\0\0\4user\0\0\0\0\0\0\0\32cn=admin,dc=spinlock,dc=hr\0\0\0\6server\0\0\0\0\0\0\0\tlocalhost\0\0\0\4port\0\0\0\1\0\0\1\205\0\0\0\10protocol\0\0\0\0\0\0\0\4ldap",
139) = 139 close(5)                                = 0
munlock(0xf7c04000, 16384)              = 0 munmap(0xf7c04000,
16384)               = 0 time(NULL)                              =
1216906861 write(4,
"0+\2\1\7`&\2\1\2\4\32cn=admin,dc=spinlock,dc=hr\200\5admin", 45) = 45
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP, revents=POLLIN}],
1, -1) = 1 read(4, "0E\2\1\7a@\n", 8)              = 8 read(4,
"\1\2\4\0\0049historical protocol version requested, use LDAPv3
instead", 63) = 63 time(NULL)                              = 1216906861
socket(PF_FILE, SOCK_STREAM, 0)         = 5 fcntl64(5, F_SETFD,
FD_CLOEXEC)         = 0

* Sven Herzberg <her...@gn...> [2008-07-18 14:55]:
> However, using your web browser you can't change the httpd.conf or
> conf.d. This applies as well to GQ (unless you use the really fancy
> fedora directory server).

I guess the question was if the cn=config backend (which is not listed
in the available namingContexts) can be accessed with GQ (possibly by
treating it as a naming context):

configContext: cn=config
namingContexts: dc=example,dc=org
monitorContext: cn=Monitor

(note that I have not tried this so this may already be possible.)

best regards,
-peter

Hi Greg,

Am Mittwoch, den 11.06.2008, 09:45 +0100 schrieb Greg Matthews:
> In the Browse options I have all options selected:
> 
> x Show Relative Distinguished Name only
> x Sort results
> x Use user friendly attribute names
> 
> At least the first two are not honoured. Full DNs are shown in the 
> object tree and the tree is not sorted. These both worked as expected in 
> 1.2.x. I'm less sure of the third option as I'm not sure what to expect 
> from it.
> 
> Are these issues related to the following STDOUT:
> 
>   $ /usr/local/bin/gq
> ** Message: FIXME: implement with GtkTreeView
> ** Message: FIXME: implement with GtkTreeView
> ** Message: FIXME: implement with GtkTreeView
> ** Message: FIXME: implement with GtkTreeView

They are, at least kind of. When rewriting the browser list, lots of
things had to be considered. It's possible that these two slipped
through my hands without noticing.

Patches to fix it should be really small, will look into it soon.

Regards,
  Sven

Pawel,

did you manage to test this?

Regards,
  Sven

Am Dienstag, den 22.01.2008, 15:42 +0100 schrieb Sven Herzberg:
> Hi Pawel,
> 
> Am Mittwoch, den 09.01.2008, 18:14 +0100 schrieb Pawel Salek:
> > I see some glitches with 1.3.3 already, the theme apparently cannot find  
> > the ldap-person icon for some reason. I will investigate first and write  
> > more thorough report later. /Paweł
> 
> I just committed a patch to trunk that should fix this. Can you please
> try revision 1163 and tell me if it works?
> 
> Regards,
>   Sven
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gqclient-discuss mailing list
> Gqc...@li...
> https://lists.sourceforge.net/lists/listinfo/gqclient-discuss

Hi Pawel,

Am Dienstag, den 22.01.2008, 18:07 +0100 schrieb Pawel Salek:
> On 01/22/2008 03:26:16 PM, Sven Herzberg wrote:
> > Hey Brandon,
> > 
> > Am Donnerstag, den 10.01.2008, 16:26 -0400 schrieb Brandon Hume:
> > > I can also open the Browse tab and click on my server, and see the  
> > basic
> > > information shown.  However - and this is where it gets weird - once I
> > > click on my base DN... not even opening the branch, just clicking on  
> > it
> > > to see the base DN attributes... I see gq go insane, caught into some
> > > kind of recursive loop that causes it to freeze while chewing up all
> > > available memory.  Attaching with gdb and getting a call stack gives
> > > something like this:
> > 
> > Can you please test GQ from subversion, now. I think your infinite
> > recursion has been gone, can you verify this?
> 
> I saw the infinite recursions with 1.3.3 but it appears to be gone now.  
> The icon problems are gone as well. I have two nitpicks only:
> 
> 1. automake complains:
> 
> test/Makefile.am:13: variable `test_ldif_SOURCES' is defined but no  
> program or
> test/Makefile.am:13: library has `test_ldif' as canonic name (possible  
> typo)
> test/Makefile.am:20: variable `test_schema_SOURCES' is defined but no  
> program or
> test/Makefile.am:20: library has `test_schema' as canonic name (possible  
> typo)

I know, I want to resurrect the test suite at some point, so I just
ignore these warnings for now.

> 2. When I modify an entry, I get "Modified (null)" message in the status  
> bar - which probably is incorrect. The modification is done just fine.

Does this still happen with the latest versions? Can you debug this?
Also, did you create, rename/move or just change the LDAP entry? 

Regards,
  Sven

Hi Tony,

Am Mittwoch, den 09.01.2008, 13:45 +0100 schrieb Tony Earnshaw:
> Sven Herzberg skrev, on 08-01-2008 19:48:
> 
> [...]
> 
> > PS: Test it. If you don't you're not in a position to claim that 1.4.0
> > is a crappy release.
> 
> Experience on FC6 ("why are you still using FC6? It's EOL and there are 
> no more updates, upgrade to FC7 at least") because I have to support 
> RHEL5 and FC6 comes the closest.
> 
> I use gq 1.0 on RHEL5 OpenLDAP 2.3.35/38 for work on a delta syncrepl 
> master provider and 3 consumer slaves, without it my life would be far 
> harder.
> 
> On my FC6 machine I use OL 2.4.7 Buchan Milne's srpm, no replication. 
> I'm used to building my own rpm specs.
> 
> ./configure with parameters doesn't make a satisfactory rpm spec file 
> (see diff)
> 
> Steps:
> install rpm made with edited spec and 1.3.3 source
> remove (mv to new name) ~/.gq from 1.0
> start gq
> edit preferences to configure server correctly:
> 
> Alternative 1:
> fill in Bind DN, choose Bind Password, Bind Type Simple, enter Yes to do 
> you still want to see the password? password is not saved.

No gnome-keyring, no saved passwords. GQ doesn't write password
information into files that can be easily read by other users of the
computer anymore.

> Alternative 2:
> fill in Bind DN, choose ask for password on first connection
> exit configuration, choose browse, Password required, enter 
> password,remember this password is greyed out - the radio button can't 
> be clicked- , choose connect, get to base DN, password isn't remembered, 
> keep on getting asked for password.

Sure, no gnome-keyring-daemon, no password saving.

> Alternative 3:
> copy original ~/.gq (with password) to .gq, start gq, edit preferences 
> server, the password isn't shown even with asterisks, bind refused for 
> rootdn, reconfigure for ask for password on first connection, attempt 
> browse password isn't remembered, keep on getting asked for password.

The password is supposed to be written to the gnome-keyring-daemon.
Unfortunately libgnomekeyring doesn't yet have support for starting the
daemon on-demand (something I want to get fixed in time for GQ 1.6).

I know that gnome-keyring is quite uncommon for several users of GQ, but
starting the daemon inside of your session (and then setting the
appropriate environment variable) should be possible. I really plan to
work on this in the future.

Regards,
  Sven

Brandon,

did you manage to get the backtrace that I asked for?

Regards,
  Sven

Am Mittwoch, den 23.01.2008, 00:59 +0100 schrieb Sven Herzberg:
> Hi Brandon,
> 
> Am Dienstag, den 22.01.2008, 16:07 -0400 schrieb Brandon Hume:
> > On Tue, 2008-01-22 at 15:26 +0100, Sven Herzberg wrote:
> > > Can you please test GQ from subversion, now. I think your infinite
> > > recursion has been gone, can you verify this?
> > 
> > I can; I'm able to load up GQ and browse the tree now, no problems yet.
> > 
> > However, trying to add a new item (by right-clicking an entity and "New"
> > -> "Use current entry") gets me a blank frame and the following on the
> > console:
> > 
> > (gq:13689): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `<invalid>'
> > 
> > (gq:13689): GLib-GObject-CRITICAL **: file gsignal.c: line 2126: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
> ...
> > I had one segfault/crash, but haven't been able to reproduce it.  Oddly
> > enough, the main GQ window remains responsive despite being able to open
> > multiple blank add-new frames.
> 
> You can turn these warnings into critical errors (eg. to get a backtrace
> in gdb) by executing with --g-fatal-warnings.
> 
> Regards,
>   Sven
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gqclient-discuss mailing list
> Gqc...@li...
> https://lists.sourceforge.net/lists/listinfo/gqclient-discuss

Davor,

did you do any further testing?

Regards,
  Sven

Am Mittwoch, den 11.06.2008, 03:07 +0200 schrieb Sven Herzberg:
> Hi Davor,
> 
> Am Dienstag, den 10.06.2008, 18:54 +0200 schrieb Davor Ocelic:
> > On Tue, 10 Jun 2008 16:57:36 +0200
> > Sven Herzberg <her...@gn...> wrote:
> > > > ** (gq:24693): CRITICAL **: gq_formfill_get_values: assertion
> > > > `GQ_IS_FORMFILL(self)' failed **
> > > > ** ERROR:(gq-input-form.c:1466):add_entry_from_formlist_no_close:
> > > > assertion failed: (formlist)
> > > 
> > > The warnings are really important to get fixed. Can you please run gq
> > > with --g-fatal-warnings and provide a backtrace then?
> > 
> > I'll do it later and report back, but I think in this case we should 
> > focus on the primary problem -- why it's not possible to add an entry,
> > instead of on the segfault that happens on the second click.
> 
> I'm not hunting the segfault; the warnings should absolutely not happen
> and something goes really wrong if they do. So fixing those should be
> the first step to solving the problem.
> 
> Regards,
>   Sven
> 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Gqclient-discuss mailing list
> Gqc...@li...
> https://lists.sourceforge.net/lists/listinfo/gqclient-discuss

Hi Brian,

I finally committed your patch to the trunk version (revision 1177).
Unfortunately I will only accept bug fixes for the 1.4 branch anymore
(to not delay it futher). It will be included in the first unstable 1.5
release.

Regards,
  Sven

Am Dienstag, den 10.06.2008, 20:03 -0700 schrieb Brian Finney:
> Thanks allot for letting me know, I never did get around to working on
> the other changes I was looking at.  I'm still using the svn checkout
> I had made so definitely looking forward to the release.
> 
> Thanks
> Brian
> 
> On Tue, Jun 10, 2008 at 7:59 AM, Sven Herzberg <her...@gn...> wrote:
> > Hi Brian,
> >
> > sorry for getting back to you that late. I really like your patch, and I
> > plan to commit it to the upcoming version (as we're currently trying to
> > fix the remaining issues on 1.4 and try to get this released ASAP).
> >
> > Regards,
> >  Sven
> >
> >

Hi,

I finally committed a patch to configure.in so we abort earlier if
msgfmt wasn't found.

Regards,
  Sven

Am Dienstag, den 10.06.2008, 18:24 +0100 schrieb Greg Matthews:
> Seem to remember this happened before but can't remember how I worked 
> around it.
> 
> make fails when working through the po directory:
> 
> Making all in po
> make[2]: Entering directory `/local/gmatt/gq-1.3.4/po'
> file=`echo cs | sed 's,.*/,,'`.gmo \
> 	  && rm -f $file &&  -o $file cs.po
> /bin/sh: -o: not found
> make[2]: *** [cs.gmo] Error 127
> make[2]: Leaving directory `/local/gmatt/gq-1.3.4/po'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/local/gmatt/gq-1.3.4'
> make: *** [all] Error 2

On Fri, 18 Jul 2008 14:55:23 +0200
Sven Herzberg <her...@gn...> wrote:

> Hi Ricio,
> 
> Am Freitag, den 18.07.2008, 12:03 +0200 schrieb Rocio Quirantes:
> > I have openLdap installed on Ubuntu, and I configured it with the
> > slapd.d configuration directory, instead of the slapd.conf file. The
> > problem is that I can't see it with GQ, can you help me?
> > Thank you
> 
> I'm not sure if I just don't understand what you want

Hey folks,

Sven, I think Ricio is thinking about a relatively new "back-config"
configuration style (slapd.d), where the configuration is not kept
in slapd.conf, but directly in the LDAP directory itself.

Actually it's not kept in the same tree with the normal data, but in a
separate tree that is populated from text files on server startup, and
saved back to files on server shutdown.

Anyway, once the config is in there in the directory, you can
view/browse/modify configuration on the fly using a LDAP browser.

You can see this tree by setting base: cn=config.

Cya,
-doc

Hi Ricio,

Am Freitag, den 18.07.2008, 12:03 +0200 schrieb Rocio Quirantes:
> I have openLdap installed on Ubuntu, and I configured it with the
> slapd.d configuration directory, instead of the slapd.conf file. The
> problem is that I can't see it with GQ, can you help me?
> Thank you

I'm not sure if I just don't understand what you want or if you have a
wrong clue of what GQ is. I'll try to explain for the second case, so if
I'm wrong, you can easily elaborate on your feature request (show other
applications, screenshots, etc.).

If we didn't do LDAP, but HTTP, consider your OpenLdap (slapd)
installation being the apache and GQ a web browser. GQ works fine for
watching data as well as modifying data (eg. data stored in a database
on the server side). However, using your web browser you can't change
the httpd.conf or conf.d. This applies as well to GQ (unless you use the
really fancy fedora directory server).

Regards,
  Sven

I have openLdap installed on Ubuntu, and I configured it with the slapd.d
configuration directory, instead of the slapd.conf file. The problem is that
I can't see it with GQ, can you help me?
Thank you
-- 
Rocío Quirantes Rodal

Hi Greg,

Am Mittwoch, den 11.06.2008, 10:17 +0100 schrieb Greg Matthews:
> Greg Matthews wrote:
> > Greg Matthews wrote:
> >> Seem to remember this happened before but can't remember how I worked 
> >> around it.
> >>
> >> make fails when working through the po directory:
> > 
> > this is now submitted as a bug (#1990590). I detail how I worked around 
> > the build bug and the resulting binary works great.
> 
> bug deleted once I could see past my own stupidity! Must have installed 
> gettext after the build failure as subsequent builds work ok.
> 
> However, it is still a bug that gq build fails when gettext is not 
> installed... should either fail at configure stage or ignore the po stuff.

Indeed, and that's why I wanted this info; I had some people
experiencing this before, but they never managed to provide the required
information for me (likely due to re-running configure after gettext
installation).

Regards,
  Sven

Greg Matthews wrote:
> Greg Matthews wrote:
>> Seem to remember this happened before but can't remember how I worked 
>> around it.
>>
>> make fails when working through the po directory:
> 
> this is now submitted as a bug (#1990590). I detail how I worked around 
> the build bug and the resulting binary works great.

bug deleted once I could see past my own stupidity! Must have installed 
gettext after the build failure as subsequent builds work ok.

However, it is still a bug that gq build fails when gettext is not 
installed... should either fail at configure stage or ignore the po stuff.

> 
> GREG
> 


-- 
Greg Matthews           01491 692445
Head of UNIX/Linux, iTSS Wallingford

-- 
This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.

Greg Matthews wrote:
> Seem to remember this happened before but can't remember how I worked 
> around it.
> 
> make fails when working through the po directory:

this is now submitted as a bug (#1990590). I detail how I worked around 
the build bug and the resulting binary works great.

GREG

-- 
Greg Matthews           01491 692445
Head of UNIX/Linux, iTSS Wallingford

In the Browse options I have all options selected:

x Show Relative Distinguished Name only
x Sort results
x Use user friendly attribute names

At least the first two are not honoured. Full DNs are shown in the 
object tree and the tree is not sorted. These both worked as expected in 
1.2.x. I'm less sure of the third option as I'm not sure what to expect 
from it.

Are these issues related to the following STDOUT:

  $ /usr/local/bin/gq
** Message: FIXME: implement with GtkTreeView
** Message: FIXME: implement with GtkTreeView
** Message: FIXME: implement with GtkTreeView
** Message: FIXME: implement with GtkTreeView

GREG
-- 
Greg Matthews           01491 692445
Head of UNIX/Linux, iTSS Wallingford

-- 
This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.