cpu-users Mailing List for Change Password Utility (Page 2)
Brought to you by:
matheny
Menu
▾
▴
cpu-users — Anything cpu related
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
(1) |
Mar
(19) |
Apr
(6) |
May
(10) |
Jun
(7) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
(10) |
Mar
(6) |
Apr
(16) |
May
(6) |
Jun
(8) |
Jul
(1) |
Aug
(5) |
Sep
(35) |
Oct
(14) |
Nov
(1) |
Dec
(4) |
| 2004 |
Jan
(3) |
Feb
(5) |
Mar
(9) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Greg M. <g.m...@it...> - 2003-10-16 15:21:43
|
as a newcomer to cpu let me first say, this software is great on linux. I've managed to compile it on solaris by providing a few libraries that are required but when it is run I get a segfault: sidhean gmatt $ gdb cpu GNU gdb 5.3 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.8"... (gdb) run Starting program: /usr/local/bin/cpu Program received signal SIGSEGV, Segmentation fault. 0xff0b3ba4 in populateGlobals () at commandline.c:704 704 globalLdap->dn = buildDn ((operation > 2) ? GROUPADD : USERADD, (gdb) bt #0 0xff0b3ba4 in populateGlobals () at commandline.c:704 #1 0xff0b8c54 in CPU_init (argc=0, argv=0x0) at ldap.c:60 #2 0x00010b34 in main (argc=1, argv=0xffbefa34) at cpu.c:95 (gdb) I changed bitvector.h to use inttypes.h instead of stdint.h and provided: features.h bits/wchar.h bits/wordsize.h sys/cdefs.h gnu/stubs.h for compilation I used gcc3.2.2. I saw a couple of requests on the archives about solaris but no confirmation of anyone running it. GREG -- Greg Matthews iTSS Wallingford 01491 692445 |
|
From: Blake M. <bma...@pu...> - 2003-10-14 09:39:53
|
Well, I implemented the local getpass function but the only places I was using it were in src/plugins/ldap/commandline.c. I didn't make the change in the getHash function, in src/util/hash.c where the libcrack password ask loop occurs. The reason this change wasn't made, is I didn't realize there was a bug with the ctrl-c/ctrl-d there :-) I was fixing a bug where certain versions of GNU getpass overwrote the static buffer used for the password, so multiple invocations of getpass would overwrite each other. So that fix went into 1.4.2, and not the ctrl-c/ctrl-d fix, which will be in 1.4.3. -Blake Whatchu talkin' 'bout, Willis? > On Mon, Oct 13, 2003 at 01:33:38PM -0500, Blake Matheny wrote: > > Hi, > > > > #215437: cpu: can not abort at password prompt > > > When creating an account using cpu it can prompt for a bad > > > password. > > > I would like to abort at that point, but that is not possible: > > > both ctrl-c and ctrl-d result in a ' is a bad password: it's > > > WAY too short' message and another password prompt. The only way > > > out is to kill cpu from another shell. > > Fixed in CVS, not in 1.4.2. This was a problem with GNU getpass, CVS has its > > own version (CPU_getpass) which respects signals, which is now used here as > > well as in other places that used getpass. > > > > About this bug... The changelog for 1.4.2 says: > > 2003-09-26 Blake Matheny <bma...@pu...> > * src/util/hash.c, src/include/util/util.h: Implemented CPU_getpass > which replicates the functionality of getpass but doesn't use a > static buffer > * src/plugins/ldap/commandline.c: Use CPU_getpass instead of getpass > > You said the bug has been fixed by this change, but it is not fixed in 1.4.2. > Is this because of some changes to CPU_getpass which are still in CVS only? > > Thanks, > > Guido > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > SourceForge.net hosts over 70,000 Open Source Projects. > See the people who have HELPED US provide better services: > Click here: http://sourceforge.net/supporters.php > _______________________________________________ > Cpu-users mailing list > Cpu...@li... > https://lists.sourceforge.net/lists/listinfo/cpu-users -- Blake Matheny "... one of the main causes of the fall of the bma...@pu... Roman Empire was that, lacking zero, they had http://www.mkfifo.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
|
From: Guido T. <ult...@qu...> - 2003-10-14 06:54:51
|
On Mon, Oct 13, 2003 at 01:33:38PM -0500, Blake Matheny wrote: Hi, > > #215437: cpu: can not abort at password prompt > > When creating an account using cpu it can prompt for a bad > > password. > > I would like to abort at that point, but that is not possible: > > both ctrl-c and ctrl-d result in a ' is a bad password: it's > > WAY too short' message and another password prompt. The only way > > out is to kill cpu from another shell. > Fixed in CVS, not in 1.4.2. This was a problem with GNU getpass, CVS has its > own version (CPU_getpass) which respects signals, which is now used here as > well as in other places that used getpass. > About this bug... The changelog for 1.4.2 says: 2003-09-26 Blake Matheny <bma...@pu...> * src/util/hash.c, src/include/util/util.h: Implemented CPU_getpass which replicates the functionality of getpass but doesn't use a static buffer * src/plugins/ldap/commandline.c: Use CPU_getpass instead of getpass You said the bug has been fixed by this change, but it is not fixed in 1.4.2. Is this because of some changes to CPU_getpass which are still in CVS only? Thanks, Guido |
|
From: Guido T. <ult...@qu...> - 2003-10-14 06:25:12
|
On Mon, Oct 13, 2003 at 04:01:01PM -0500, Blake Matheny wrote: Hi, > With the configuration file given below, there should be no group named > 'debug'. In order to automatically create the users group, USERGROUPS must be > set to yes which I see USERGROUPS is not even in your configuration file. If > USERGROUPS is nonexistant (or set to no) cpu looks for a USERS_GID entry, > specifying the default gid to use. That is also not set in your configuration > file, so cpu defaults to using gid 100 at this point. When you try and > 'groupdel debug' it is normal to see 'No such object', since the object wasn't > created :-) > > Try adding 'USERGROUPS = yes' to your configuration file and let me know if > you still have the same problem. > Thanks, that fixes the problem! > Also, I can see by your error messages that you aren't using 1.4.2. I would > suggest you upgrade, as the error messages are significantly better. > Well, I'm using the debian version... I'll upgrade to 1.4.2 asap! :) Bye, and thanks, Guido |
|
From: Blake M. <bma...@pu...> - 2003-10-13 21:04:46
|
Whatchu talkin' 'bout, Willis? > On Mon, Oct 13, 2003 at 01:33:38PM -0500, Blake Matheny wrote: > [snip] > So, will these two be in 1.4.3? Yes, bugfixes always go into the next release unless they are urgent, e.g. they cause cpu to fail on major operations. Since the 1.4 series is no longer a development series, it is safe for users to check it out and compile. > I've just reproduced it... > > executor:~# cpu useradd -E debug debug > > > User debug successfully added! > executor:~# cpu usermod -g 100 debug > > User debug successfully modified! > executor:~# cpu groupdel debug > > ldap: ldapGroupDel: ldap_delete_s: No such object (32) > matched DN: ou=Groups,dc=studio,dc=tixteam,dc=net > ldap: CPU_init: Error in ldapOperation. > Something went wrong. Exiting. > executor:~# > [snip] With the configuration file given below, there should be no group named 'debug'. In order to automatically create the users group, USERGROUPS must be set to yes which I see USERGROUPS is not even in your configuration file. If USERGROUPS is nonexistant (or set to no) cpu looks for a USERS_GID entry, specifying the default gid to use. That is also not set in your configuration file, so cpu defaults to using gid 100 at this point. When you try and 'groupdel debug' it is normal to see 'No such object', since the object wasn't created :-) Try adding 'USERGROUPS = yes' to your configuration file and let me know if you still have the same problem. Also, I can see by your error messages that you aren't using 1.4.2. I would suggest you upgrade, as the error messages are significantly better. > > [LDAP] > #LDAP_HOST = 127.0.0.1 > #LDAP_PORT = 389 > # Can also use LDAP_URI = ldaps://localhost:389 for TLS support > LDAP_URI = ldap://ldap.studio.tixteam.net > BIND_DN = cn=admin,dc=studio,dc=tixteam,dc=net > BIND_PASS = mypass > USER_BASE = ou=People,dc=studio,dc=tixteam,dc=net > GROUP_BASE = ou=Groups,dc=studio,dc=tixteam,dc=net > USER_OBJECT_CLASS = inetOrgPerson,posixAccount,shadowAccount,top > GROUP_OBJECT_CLASS = posixGroup,top > USER_FILTER = (objectClass=posixAccount) > GROUP_FILTER = (objectClass=posixGroup) > USER_CN_STRING = uid > GROUP_CN_STRING = cn > SKEL_DIR = /etc/skel > DEFAULT_SHELL = /bin/bash > HOME_DIRECTORY = /home > MAX_UIDNUMBER = 10000 > MIN_UIDNUMBER = 1000 > MAX_GIDNUMBER = 10000 > MIN_GIDNUMBER = 1000 > ID_MAX_PASSES = 1000 > RANDOM = "false" > PASSWORD_FILE = "/etc/passfile" > SHADOW_FILE = "/etc/shadowfile" > HASH = "md5" > SHADOWLASTCHANGE = 11192 > SHADOWMAX = 99999 > SHADOWWARING = 7 > SHADOWEXPIRE = -1 > SHADOWFLAG = 134538308 > SHADOWMIN = -1 > SHADOWINACTIVE = -1 > > END. > > Thanks, > > Guido > -Blake -- Blake Matheny "... one of the main causes of the fall of the bma...@pu... Roman Empire was that, lacking zero, they had http://www.mkfifo.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
|
From: Guido T. <ult...@qu...> - 2003-10-13 20:46:48
|
On Mon, Oct 13, 2003 at 01:33:38PM -0500, Blake Matheny wrote: Hi, > > #215258: cpu: problematic error recovery > > If cpu fails to create a user for some reason it exists. > > But at that stage is has already created a group for the user. > > Please try to clean up after the error and remove the new group > > as well so the ldap directory will be left in its original state. > > > > As extra information for this bugreport: it is impossible to remove > > the leftover group with cpu, since it will complain that it is a > > users' primary group and can not be removed. > Fixed in CVS, not in 1.4.2. Now a group isn't added for the user unless the > user was successfully added. > > > #215437: cpu: can not abort at password prompt > > When creating an account using cpu it can prompt for a bad > > password. > > I would like to abort at that point, but that is not possible: > > both ctrl-c and ctrl-d result in a ' is a bad password: it's > > WAY too short' message and another password prompt. The only way > > out is to kill cpu from another shell. > Fixed in CVS, not in 1.4.2. This was a problem with GNU getpass, CVS has its > own version (CPU_getpass) which respects signals, which is now used here as > well as in other places that used getpass. > So, will these two be in 1.4.3? > > #215298: cpu: strange error removing groups > > This is somewhat unexpected: > > > > vortex:~# cpu useradd -E debug debug > > User debug successfully added! > > vortex:~# cpu usermod -g 100 debug > > User debug successfully modified! > > vortex:~# cpu groupdel debug > > ldap: checkIsPrimaryGroup: ldap_search_st: No such object (32) > > groupdel: cannot remove user's primary group. > > ldap: CPU_init: Error in ldapOperation. > > Something went wrong. Exiting. > I'm unable to replicate this with either cpu 1.4.1 or 1.4.2. Would it be > possible for the user to try again, and if the error happens again could I get > a copy of their configuration file? > I've just reproduced it... executor:~# cpu useradd -E debug debug User debug successfully added! executor:~# cpu usermod -g 100 debug User debug successfully modified! executor:~# cpu groupdel debug ldap: ldapGroupDel: ldap_delete_s: No such object (32) matched DN: ou=Groups,dc=studio,dc=tixteam,dc=net ldap: CPU_init: Error in ldapOperation. Something went wrong. Exiting. executor:~# My configuration file follows: BEGIN: # See cpu.conf(5) for documentation [GLOBAL] DEFAULT_METHOD = ldap CRACKLIB_DICTIONARY = /var/cache/cracklib/cracklib_dict [LDAP] #LDAP_HOST = 127.0.0.1 #LDAP_PORT = 389 # Can also use LDAP_URI = ldaps://localhost:389 for TLS support LDAP_URI = ldap://ldap.studio.tixteam.net BIND_DN = cn=admin,dc=studio,dc=tixteam,dc=net BIND_PASS = mypass USER_BASE = ou=People,dc=studio,dc=tixteam,dc=net GROUP_BASE = ou=Groups,dc=studio,dc=tixteam,dc=net USER_OBJECT_CLASS = inetOrgPerson,posixAccount,shadowAccount,top GROUP_OBJECT_CLASS = posixGroup,top USER_FILTER = (objectClass=posixAccount) GROUP_FILTER = (objectClass=posixGroup) USER_CN_STRING = uid GROUP_CN_STRING = cn SKEL_DIR = /etc/skel DEFAULT_SHELL = /bin/bash HOME_DIRECTORY = /home MAX_UIDNUMBER = 10000 MIN_UIDNUMBER = 1000 MAX_GIDNUMBER = 10000 MIN_GIDNUMBER = 1000 ID_MAX_PASSES = 1000 RANDOM = "false" PASSWORD_FILE = "/etc/passfile" SHADOW_FILE = "/etc/shadowfile" HASH = "md5" SHADOWLASTCHANGE = 11192 SHADOWMAX = 99999 SHADOWWARING = 7 SHADOWEXPIRE = -1 SHADOWFLAG = 134538308 SHADOWMIN = -1 SHADOWINACTIVE = -1 END. Thanks, Guido |
|
From: Blake M. <bma...@pu...> - 2003-10-13 18:37:17
|
Comments below: Whatchu talkin' 'bout, Willis? > > Hi, > > As you know Paul J Stevens and me have been working on an official Debian > package for cpu. Many thanks! > [snip] > > The reported problems are: > > #215258: cpu: problematic error recovery > If cpu fails to create a user for some reason it exists. > But at that stage is has already created a group for the user. > Please try to clean up after the error and remove the new group > as well so the ldap directory will be left in its original state. > > As extra information for this bugreport: it is impossible to remove > the leftover group with cpu, since it will complain that it is a > users' primary group and can not be removed. Fixed in CVS, not in 1.4.2. Now a group isn't added for the user unless the user was successfully added. > #215298: cpu: strange error removing groups > This is somewhat unexpected: > > vortex:~# cpu useradd -E debug debug > User debug successfully added! > vortex:~# cpu usermod -g 100 debug > User debug successfully modified! > vortex:~# cpu groupdel debug > ldap: checkIsPrimaryGroup: ldap_search_st: No such object (32) > groupdel: cannot remove user's primary group. > ldap: CPU_init: Error in ldapOperation. > Something went wrong. Exiting. I'm unable to replicate this with either cpu 1.4.1 or 1.4.2. Would it be possible for the user to try again, and if the error happens again could I get a copy of their configuration file? > #215437: cpu: can not abort at password prompt > When creating an account using cpu it can prompt for a bad > password. > I would like to abort at that point, but that is not possible: > both ctrl-c and ctrl-d result in a ' is a bad password: it's > WAY too short' message and another password prompt. The only way > out is to kill cpu from another shell. Fixed in CVS, not in 1.4.2. This was a problem with GNU getpass, CVS has its own version (CPU_getpass) which respects signals, which is now used here as well as in other places that used getpass. -Blake -- Blake Matheny "... one of the main causes of the fall of the bma...@pu... Roman Empire was that, lacking zero, they had http://www.mkfifo.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
|
From: Guido T. <ult...@de...> - 2003-10-13 08:58:13
|
Hi, As you know Paul J Stevens and me have been working on an official Debian package for cpu. The status is that cpu 1.4.1 has found its way into the debian archive, there is a version in unstable and another one in testing, and it will quite probably ship with the Debian GNU/Linux sarge, to be released as Debian stable one of the next months. Now the main focus is on preparing a package for 1.4.2. Anyway we've had some bug reports in the Debian BTS about cpu, and we'd like to share them with you, and have a comment on whether they have been fixed in 1.4.2 or will be fixed in some other version... The reported problems are: #215258: cpu: problematic error recovery If cpu fails to create a user for some reason it exists. But at that stage is has already created a group for the user. Please try to clean up after the error and remove the new group as well so the ldap directory will be left in its original state. As extra information for this bugreport: it is impossible to remove the leftover group with cpu, since it will complain that it is a users' primary group and can not be removed. #215298: cpu: strange error removing groups This is somewhat unexpected: vortex:~# cpu useradd -E debug debug User debug successfully added! vortex:~# cpu usermod -g 100 debug User debug successfully modified! vortex:~# cpu groupdel debug ldap: checkIsPrimaryGroup: ldap_search_st: No such object (32) groupdel: cannot remove user's primary group. ldap: CPU_init: Error in ldapOperation. Something went wrong. Exiting. #215437: cpu: can not abort at password prompt When creating an account using cpu it can prompt for a bad password. I would like to abort at that point, but that is not possible: both ctrl-c and ctrl-d result in a ' is a bad password: it's WAY too short' message and another password prompt. The only way out is to kill cpu from another shell. The credit for these reports goes to Wichert Akkerman. Thanks for your attention, and for your work on cpu! Bye, Guido -- Guido Trotter Debian GNU/Linux http://www.cs.unibo.it/~trotter/ |
|
From: Blake M. <bma...@pu...> - 2003-10-13 02:51:20
|
Hello All, cpu 1.4.2 was released today and is available at: http://sourceforge.net/project/showfiles.php?group_id=45948 This release is the last release in the 1.4 series to contain new features. The only new features that will be added are ones that will not possibly introduce new bugs into existing functionality. The only changes other then that will be bug fixes. The reason for this is I'm going to be branching a 1.5 series which will include a rewrite of the API interfaces. In order to alleviate problems with upstream maintainers and bugs, a feature freeze on the 1.4 series is needed. A rewrite of the API interfaces is needed in order to better facilitate people writing other backends. The existing 'API' is unfortunately fairly useless. There were three big changes to this release. The first was the move from synchronous to asynchronous searches, the second was the combination of using asynchronous searches with a bitvector, and the third was the way the help works. Comparison between adding a user with version 1.4.1 and 1.4.2: # users RANDOM=? Version Time 1000 true 1.4.1 0m0.421s 1000 false 1.4.1 3m34.848s # users RANDOM=? Version Time 1000 true 1.4.2 0m0.437s 1000 false 1.4.2 0m0.547s # users RANDOM=? Version Time 5000 true 1.4.1 0m2.448s 5000 false 1.4.1 130m19.123s # users RANDOM=? Version Time 5000 true 1.4.2 0m3.530s 5000 false 1.4.2 0m1.887s where '# users' was the number of users in the directory (uid 0-#), RANDOM=? was the setting random in cpu.conf. The rest is self explanatory. The time difference was significant enough that I thought this warranted a release. I also overhauled the error reporting mechanism to give users useful feedback as to what the error was and what can be done to resolve this. The reason for doing this was two fold. First, to allow for better internationalization support and the second because most of the OpenLDAP error messages are terrible. There were some minor bug fixes as well. -Blake -- Blake Matheny "... one of the main causes of the fall of the bma...@pu... Roman Empire was that, lacking zero, they had http://www.mkfifo.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
|
From: SourceForge.net <no...@so...> - 2003-10-10 08:39:25
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2231002 By: nobody How can I chane the password of a ldap user ? I have read the manual page and I don't understand how can I do it. Thanks ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=150496 |
|
From: Blake M. <bma...@pu...> - 2003-09-27 02:52:02
|
I *think* I figured out what is going on here. From the getpass man page: "The function getpass returns a pointer to a static buffer containing the password without the trailing newline, terminated by a NULL. This buffer may be overwritten by a following call." Since getpass is being called more than once, I think the buffer is being overwritten. Elsewhere in the man page it says: "This function is obsolete. Do not use it." So I implemented a new version of it that doesn't use a static buffer. Could you check out the CVS version of cpu and let me know if it fixed your problem? Also, let me know if adding a user is faster for you. There is no more GRAB* options, it just defaults to doing that unless random is true. -Blake Whatchu talkin' 'bout, Willis? > Well if I putting in the wrong password I am doing it consistently with > one way of setting the user password and not the other. > > root@llama /usr/local/src# cpu -w useradd -p test > Please enter the LDAP bind password: > Please enter desired user password: > > ldap: ldapOperation: ldap_bind_s: Invalid credentials (49) > ldap: CPU_init: Error in ldapOperation. > Something went wrong. Exiting. > You have new mail in /var/spool/mail/root > root@llama /usr/local/src# cpu -w useradd -p test > Please enter the LDAP bind password: > Please enter desired user password: > -- Blake Matheny "... one of the main causes of the fall of the bma...@pu... Roman Empire was that, lacking zero, they had http://www.mkfifo.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
|
From: Blake M. <bma...@pu...> - 2003-09-27 01:45:17
|
Here is the official report, now that I have the bugs worked out. Expect this
feature for the next release.
Configuration file was mostly default, except that USERGROUPS is set to YES
so for each useradd the is a groupadd. For this who don't want to read on,
here is the summary:
It is always a bad idea to set GRAB_ALL_UIDS/GRAB_ALL_GIDS to false and RANDOM
to false, so I'm going to make the change that GRAB_ALL_UIDS/GRAB_ALL_GIDS is
true by default. It can be faster to set GRAB_ALL_UIDS/GRAB_ALL_GIDS to false
and RANDOM to true, but most people like some type of linear ordering. Note
that in some cases setting GRAB_ALL* to true was nearly 7 times faster than
setting it to false with RANDOM set to false.
------------------------------------------------------
First set of tests. Empty directory, adding 300 users.
------------------------------------------------------
GRAB_ALL_UIDS and GRAB_ALL_GIDS set to true.
[crimson 70] tests > time ./useradd.pl 0 299
...
real 2m34.507s
user 0m1.560s
sys 0m1.100s
GRAB_ALL_UIDS and GRAB_ALL_GIDS set to false and RANDOM set to false.
[crimson 71] tests > time ./useradd.pl 0 299
...
real 3m55.956s
user 0m8.850s
sys 0m3.740s
GRAB_ALL_UIDS and GRAB_ALL_GIDS set to false and RANDOM set to true.
[crimson 71] tests > time ./useradd.pl 0 299
...
real 2m13.783s
user 0m1.870s
sys 0m0.850s
-----------------------------------------------------------------------------
Second set of tests. Directory contains 300 linear users (using uid/gids from
100-400), adding 300 users.
-----------------------------------------------------------------------------
GRAB_ALL_UIDS and GRAB_ALL_GIDS set to true.
[crimson 72] tests > time ./useradd.pl 299 599
...
real 2m49.624s
user 0m3.580s
sys 0m1.780s
GRAB_ALL_UIDS and GRAB_ALL_GIDS set to false and RANDOM set to false.
[crimson 73] tests > time ./useradd.pl 299 599
...
real 14m45.240s
user 0m26.620s
sys 0m11.330s
GRAB_ALL_UIDS and GRAB_ALL_GIDS set to false and RANDOM set to true.
[crimson 71] tests > time ./useradd.pl 299 599
...
real 2m33.843s
user 0m1.780s
sys 0m0.950s
-----------------------------------------------------------------------------
Third set of tests. Directory contains 300 random users. The uid/gid space is
600 and half that is used, adding 300 users.
-----------------------------------------------------------------------------
GRAB_ALL_UIDS and GRAB_ALL_GIDS set to true.
[crimson 72] tests > time ./useradd.pl 299 599
...
real 2m50.964s
user 0m3.570s
sys 0m1.750s
GRAB_ALL_UIDS and GRAB_ALL_GIDS set to false and RANDOM set to false.
[crimson 73] tests > time ./useradd.pl 299 599
...
real 10m13.949s
user 0m18.030s
sys 0m8.410s
GRAB_ALL_UIDS and GRAB_ALL_GIDS set to false and RANDOM set to true.
[crimson 71] tests > time ./useradd.pl 299 599
...
real 2m48.698s
user 0m2.290s
sys 0m1.250s
-Blake
Whatchu talkin' 'bout, Willis?
> Blake Matheny wrote:
>
> >Well, there are a couple of issues here to consider. If there is a large
> >userbase, grabbing all of the IDs could be terribly slow.
> >
>
> I guess part of the problem is the sparseness of the ldap system for
> complex optimized queries. no select max(uid) from users :)
>
> I would think that even in this worst case getting a single large query
> should be an order of magnitude faster than several hundred individual
> queries and would scale a lot better. Right now the real speed problem
> I think is not the sorting it is the constant queries to the directory.
> Even a linear search of an unordered list that is grabbed from the
> directory in one query would be a lot faster than the current setup I think.
>
> Instead of a binary tree you could set up a linked list and do a
> quicksort. Not having a complex data structure should be ok since we are
> not "searching" the list, rather we are sorting it and grabbing the max
> value. This does not find holes in the list of UIDs but it does give you
> constantly incrementing UID and GID's. Of course if you want to find
> holes a binary tree insertion plus search for the lowest available gap
> would work too, perhaps that is a more general solution.
>
> In the interim I guess I will use the following technique, either
> manually or in a script which accomplishes the same thing externally to cpu.
>
> # cpu -w cat| awk -F : {'print $3'} | sort | uniq|tail -n 1
> 5545
> # cpu -w useradd -u 5546 -g 5546 -ptest test3
>
> btw Blake thank you for cpu, it is exactly the kind of tool that is
> needed to interface well with the use of LDAP in authentication. There
> are very few similar tools that I have found and none that work nearly
> as well.
>
> Thanks,
>
> Terrence
>
--
Blake Matheny "... one of the main causes of the fall of the
bma...@pu... Roman Empire was that, lacking zero, they had
http://www.mkfifo.net no way to indicate successful termination of
http://ovmj.org/GNUnet/ their C programs." --Robert Firth
|
|
From: Blake M. <bma...@pu...> - 2003-09-25 22:05:35
|
[duke 12] cpu > rm -f ~/lib/libcpu* [duke 13] cpu > ls ~/lib/libcpu* ls: /home/bmatheny/lib/libcpu*: No such file or directory [duke 13] cpu > ./configure --prefix=$HOME ... [duke 14] cpu > make install ... [duke 15] cpu > ls -p ~/lib/libcpu* /home/bmatheny/lib/libcpu_ldap.a /home/bmatheny/lib/libcputil.a /home/bmatheny/lib/libcpu_ldap.la /home/bmatheny/lib/libcputil.la /home/bmatheny/lib/libcpu_ldap.so@ /home/bmatheny/lib/libcputil.so@ /home/bmatheny/lib/libcpu_ldap.so.0@ /home/bmatheny/lib/libcputil.so.0@ /home/bmatheny/lib/libcpu_ldap.so.0.0.0 /home/bmatheny/lib/libcputil.so.0.0.0 You can see that the libcpu-ldap.so file is created as a symlink (to libcpu_ldap.so.0.0.0). It could be a problem with the debian build, it might not be :-) Could you run the ./contrib/report.sh script and send me the results? Here is the output from me running it: Please submit the following information with your bug report: -------------------------------------------------------------- OS : Linux OS RELEASE : 2.4.20-4GB-athlon HARDWARE : i686 gcc version : gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux) Gnu gmake : 3.80 libtool : 1.4.3 autoconf : 2.57 automake : 1.7.2 ld : 2.13.90.0.18 -------------------------------------------------------------- -Blake Whatchu talkin' 'bout, Willis? > > Hi, > > I've noticed that, while cpu up to 1.4.0 saved libcputil and libcpu-ldap in > libcputil.so.0.0.0 and libcpu-ldap.so.0.0.0 (and relative symlinks) with > 1.4.1 the .so seems to be missing... So cpu doesn't start, complaining it > cannot find libcpu-ldap.so. As a quick solution, adding back the symlink to > the other file fixes the problem, anyway I thought it would be better to > ask here about this... > > Am I doing something wrong in building the debian package or is there an > error in the build/install system? > > Thanks, > > Guido > > -- > Guido Trotter > Jabber ID: ult...@ja... > Public PGP key available on: http://www.cs.unibo.it/~trotter/ > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Cpu-users mailing list > Cpu...@li... > https://lists.sourceforge.net/lists/listinfo/cpu-users -- Blake Matheny "... one of the main causes of the fall of the bma...@pu... Roman Empire was that, lacking zero, they had http://www.mkfifo.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
|
From: Guido T. <ult...@de...> - 2003-09-25 20:53:29
|
Hi, I've noticed that, while cpu up to 1.4.0 saved libcputil and libcpu-ldap in libcputil.so.0.0.0 and libcpu-ldap.so.0.0.0 (and relative symlinks) with 1.4.1 the .so seems to be missing... So cpu doesn't start, complaining it cannot find libcpu-ldap.so. As a quick solution, adding back the symlink to the other file fixes the problem, anyway I thought it would be better to ask here about this... Am I doing something wrong in building the debian package or is there an error in the build/install system? Thanks, Guido -- Guido Trotter Jabber ID: ult...@ja... Public PGP key available on: http://www.cs.unibo.it/~trotter/ |
|
From: Terrence M. <tm...@ph...> - 2003-09-25 20:29:24
|
Blake Matheny wrote:
>Well, there are a couple of issues here to consider. If there is a large
>userbase, grabbing all of the IDs could be terribly slow.
>
I guess part of the problem is the sparseness of the ldap system for
complex optimized queries. no select max(uid) from users :)
I would think that even in this worst case getting a single large query
should be an order of magnitude faster than several hundred individual
queries and would scale a lot better. Right now the real speed problem
I think is not the sorting it is the constant queries to the directory.
Even a linear search of an unordered list that is grabbed from the
directory in one query would be a lot faster than the current setup I think.
Instead of a binary tree you could set up a linked list and do a
quicksort. Not having a complex data structure should be ok since we are not
"searching" the list, rather we are sorting it and grabbing the max
value. This does not find holes in the list of UIDs but it does give you
constantly incrementing UID and GID's. Of course if you want to find
holes a binary tree insertion plus search for the lowest available gap
would work too, perhaps that is a more general solution.
In the interim I guess I will use the following technique, either
manually or in a script which accomplishes the same thing externally to cpu.
# cpu -w cat| awk -F : {'print $3'} | sort | uniq|tail -n 1
5545
# cpu -w useradd -u 5546 -g 5546 -ptest test3
btw Blake thank you for cpu, it is exactly the kind of tool that is
needed to interface well with the use of LDAP in authentication. There
are very few similar tools that I have found and none that work nearly
as well.
Thanks,
Terrence
> If there isn't a
>large user base, the problem is that the order in which users (or groups) are
>returned is not by UID/GID, but rather by time of last modification (usually).
>So as we are grabbing UIDs/GIDs, we would need to insert them into a binary
>tree (or something similar), then search the tree. We could do this also with
>a bitvector (which would likely be faster and smaller) but both take up extra
>memory and time. I'll have to think about it.
>
>Of course, setting MIN_UID to the MAX_UID in use would still allow for fast
>linear searches as Eric suggested, but it's not ideal.
>
>Ideas welcome.
>
>-Blake
>
>Whatchu talkin' 'bout, Willis?
>
>
>>That should but I would like both, linear and relatively quick.
>>
>>CPU seems to do a lot of small searchs, could it not get the list of
>>UIDs in one go and then figure out the UID to use from there internally?
>>A cpu -w cat comes back in a little over 2 seconds on my system and only
>>makes one query to the directory rather than searching one entry at a
>>time to determine its relatively usefulness.
>>
>>For example if you run the following you quickly get a sorted list of
>>all the existing UID's
>>
>>cpu -w cat| awk -F : {'print $3'} | sort | uniq
>>
>>Then just grab the last one, increment by one and you are done. I can do
>>this by hand of course but having CPU do it for me is nicer. :)
>>
>>That would also avoid the need to cache the UID.
>>
>>Terrence
>>
>>
>>
>
>
>
|
|
From: Terrence M. <tm...@ph...> - 2003-09-25 18:59:05
|
Well if I putting in the wrong password I am doing it consistently with
one way of setting the user password and not the other.
root@llama /usr/local/src# cpu -w useradd -p test
Please enter the LDAP bind password:
Please enter desired user password:
ldap: ldapOperation: ldap_bind_s: Invalid credentials (49)
ldap: CPU_init: Error in ldapOperation.
Something went wrong. Exiting.
You have new mail in /var/spool/mail/root
root@llama /usr/local/src# cpu -w useradd -p test
Please enter the LDAP bind password:
Please enter desired user password:
ldap: ldapOperation: ldap_bind_s: Invalid credentials (49)
ldap: CPU_init: Error in ldapOperation.
Something went wrong. Exiting.
root@llama /usr/local/src# cpu -w useradd -p test
Please enter the LDAP bind password:
Please enter desired user password:
ldap: ldapOperation: ldap_bind_s: Invalid credentials (49)
ldap: CPU_init: Error in ldapOperation.
Something went wrong. Exiting.
root@llama /usr/local/src# cpu -w useradd -ptest test
Please enter the LDAP bind password:
User test successfully added!
So the question is could this have to do with ACL's in my LDAP directory
and how I set pw?
Failed Log
Sep 25 11:54:26 llama slapd[2213]: conn=2432 fd=21 ACCEPT from
IP=127.0.0.1:32860 (IP=0.0.0.0:389)
Sep 25 11:54:26 llama slapd[2443]: conn=2432 op=0 BIND
dn="cn=Admin,dc=physics,dc=ucsd,dc=edu" method=128
Sep 25 11:54:26 llama slapd[2443]: conn=2432 op=0 RESULT tag=97 err=49 text=
Sep 25 11:54:26 llama slapd[2213]: conn=2432 fd=21 closed
Sep 25 11:54:46 llama slapd[2213]: conn=2433 fd=21 ACCEPT from
IP=127.0.0.1:32861 (IP=0.0.0.0:389)
Sep 25 11:54:46 llama slapd[4908]: conn=2433 op=0 BIND
dn="cn=Admin,dc=physics,dc=ucsd,dc=edu" method=128
Sep 25 11:54:46 llama slapd[4908]: conn=2433 op=0 RESULT tag=97 err=49 text=
Sep 25 11:54:46 llama slapd[2213]: conn=2433 fd=21 closed
Sep 25 11:55:24 llama slapd[2434]: conn=2434 op=3 SRCH attr=cn
userPassword memberUid uniqueMember gidNumber
Sep 25 11:55:24 llama slapd[2434]: conn=2434 op=3 SEARCH RESULT tag=101
err=0 nentries=0 text=
Sep 25 11:55:24 llama slapd[2213]: conn=2434 fd=21 closed
Success Log
Sep 25 11:56:31 llama slapd[2213]: conn=2435 fd=21 ACCEPT from
IP=127.0.0.1:32862 (IP=0.0.0.0:389)
Sep 25 11:56:31 llama slapd[2443]: conn=2435 op=0 BIND
dn="cn=Admin,dc=physics,dc=ucsd,dc=edu" method=128
Sep 25 11:56:31 llama slapd[2443]: conn=2435 op=0 BIND
dn="cn=Admin,dc=physics,dc=ucsd,dc=edu" mech=simple ssf=0
Sep 25 11:56:31 llama slapd[2443]: conn=2435 op=0 RESULT tag=97 err=0 text=
Sep 25 11:56:31 llama slapd[4908]: conn=2435 op=1 SRCH
base="ou=People,dc=physics,dc=ucsd,dc=edu" scope=2 filter="(uidNumber=5010)"
... lots of uid searching ensues....
Sep 25 11:57:34 llama slapd[4355]: conn=2435 op=1071 SRCH attr=gidNumber
Sep 25 11:57:34 llama slapd[4355]: conn=2435 op=1071 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Sep 25 11:57:34 llama slapd[4906]: conn=2435 op=1072 SRCH
base="ou=Group,dc=physics,dc=ucsd,dc=edu" scope=2 filter="(gidNumber=5545)"
Sep 25 11:57:34 llama slapd[4906]: conn=2435 op=1072 SRCH attr=gidNumber
Sep 25 11:57:34 llama slapd[4906]: conn=2435 op=1072 SEARCH RESULT
tag=101 err=0 nentries=0 text=
Sep 25 11:57:34 llama slapd[2434]: conn=2435 op=1073 ADD
dn="cn=test2,ou=Group,dc=physics,dc=ucsd,dc=edu"
Sep 25 11:57:34 llama slapd[2434]: conn=2435 op=1073 RESULT tag=105
err=0 text=
Sep 25 11:57:34 llama slapd[2443]: conn=2435 op=1074 ADD
dn="uid=test2,ou=People,dc=physics,dc=ucsd,dc=edu"
Sep 25 11:57:34 llama slapd[2443]: conn=2435 op=1074 RESULT tag=105
err=0 text=
Sep 25 11:57:34 llama slapd[2213]: conn=2435 fd=21 closed
Sep 25 11:57:37 llama slapd[4908]: conn=828 op=291 SRCH
base="dc=physics,dc=ucsd,dc=edu" scope=2
filter="(&(objectClass=posixAccount)(uidNumber=5004))"
Sep 25 11:57:37 llama slapd[4908]: conn=828 op=291 SRCH attr=uid
userPassword uidNumber gidNumber cn homeDirectory loginShell gecos
description objectClass
Sep 25 11:57:37 llama slapd[4908]: conn=828 op=291 SEARCH RESULT tag=101
err=0 nentries=1 text=
Here are my ACL's. I explicitly restrict access to the userPassword
field for security reasons, ie if you are not said user you cannot see
the hash. However why one method works and the other does not is odd.
# Restrict userPassword to be used for auth only, but allow users to
modify their passwords
access to attrs=userPassword
by self write
by * auth
# Default simple acl
access to *
by * read
Terrence
Blake Matheny wrote:
>[duke 8] bmatheny > cpu -w useradd -p test
>Please enter the LDAP bind password:
>Please enter desired user password:
>
>User test successfully added!
>
>[duke 9] bmatheny > cpu -w cat
>Please enter the LDAP bind password:
>User Accounts
>blake:x:100:100::/home/blake:/bin/bash
>blah:x:4506:5511::/home/blah:/bin/bash
>test:x:6099:5947::/home/test:/bin/bash
>
>Group Entries
>blake:x:100:
>blah:x:5511:
>test:x:8114:
>
>[duke 10] bmatheny > cpu --version
>CPU 1.4.1
>Written by Blake Matheny
>Copyright 2001, 2002, 2003
>
>
>Is it possible you entered the wrong password for the first one there? It
>works for me, is anyone else having this problem? What version are you using?
>
>-Blake
>
>Whatchu talkin' 'bout, Willis?
>
>
>>I am having problems when trying to set a user accounts password
>>interactively.
>>
>>root@llama /usr/local/src# cpu -w useradd -p test
>>Please enter the LDAP bind password:
>>Please enter desired user password:
>>
>>ldap: ldapOperation: ldap_bind_s: Invalid credentials (49)
>>ldap: CPU_init: Error in ldapOperation.
>>Something went wrong. Exiting.
>>root@llama /usr/local/src# gq &
>>[4] 11748
>>root@llama /usr/local/src# cpu -w useradd -ptest test
>>Please enter the LDAP bind password:
>>User test successfully added!
>>root@llama /usr/local/src#
>>
>>Any ideas?
>>
>>Terrence
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by:ThinkGeek
>>Welcome to geek heaven.
>>http://thinkgeek.com/sf
>>_______________________________________________
>>Cpu-users mailing list
>>Cpu...@li...
>>https://lists.sourceforge.net/lists/listinfo/cpu-users
>>
>>
>
>
>
|
|
From: Lukas K. <lu...@kn...> - 2003-09-25 12:27:28
|
Am Mi, 2003-09-24 um 22.27 schrieb Terrence Martin:
> I am noticing that when adding new users the command take a considerable
> amount of time to come back. Presumably this is as the result of
> searching for unused gid or uid.
A qoute from cpu.conf(5):
-- snip --
RANDOM = true or false
If RANDOM is true, then a random number will be generated and
searched for (this number, if unused in the directory, will be
the users uid or a groups gid). If a user or group with that ID
exists, the process will continue for ID_MAX_PASSES. If true, a
linear scan will be done starting at MIN_UIDNUMBER (or GIDNUM-
BER) and will not stop until an unused ID is found or the number
of scans is equal to ID_MAX_PASSES
-- snap --
If I interpret this correctly, it would solve your problem (speed),
because there don't have to be much ldap-questions for finding a free
uid.
> Terrence
--
bye
Lukas
|
|
From: Blake M. <bma...@pu...> - 2003-09-25 00:55:23
|
Well, there are a couple of issues here to consider. If there is a large
userbase, grabbing all of the IDs could be terribly slow. If there isn't a
large user base, the problem is that the order in which users (or groups) are
returned is not by UID/GID, but rather by time of last modification (usually).
So as we are grabbing UIDs/GIDs, we would need to insert them into a binary
tree (or something similar), then search the tree. We could do this also with
a bitvector (which would likely be faster and smaller) but both take up extra
memory and time. I'll have to think about it.
Of course, setting MIN_UID to the MAX_UID in use would still allow for fast
linear searches as Eric suggested, but it's not ideal.
Ideas welcome.
-Blake
Whatchu talkin' 'bout, Willis?
>
> That should but I would like both, linear and relatively quick.
>
> CPU seems to do a lot of small searchs, could it not get the list of
> UIDs in one go and then figure out the UID to use from there internally?
> A cpu -w cat comes back in a little over 2 seconds on my system and only
> makes one query to the directory rather than searching one entry at a
> time to determine its relatively usefulness.
>
> For example if you run the following you quickly get a sorted list of
> all the existing UID's
>
> cpu -w cat| awk -F : {'print $3'} | sort | uniq
>
> Then just grab the last one, increment by one and you are done. I can do
> this by hand of course but having CPU do it for me is nicer. :)
>
> That would also avoid the need to cache the UID.
>
> Terrence
>
--
Blake Matheny "... one of the main causes of the fall of the
bma...@pu... Roman Empire was that, lacking zero, they had
http://www.mkfifo.net no way to indicate successful termination of
http://ovmj.org/GNUnet/ their C programs." --Robert Firth
|
|
From: Blake M. <bma...@pu...> - 2003-09-25 00:04:06
|
[duke 8] bmatheny > cpu -w useradd -p test Please enter the LDAP bind password: Please enter desired user password: User test successfully added! [duke 9] bmatheny > cpu -w cat Please enter the LDAP bind password: User Accounts blake:x:100:100::/home/blake:/bin/bash blah:x:4506:5511::/home/blah:/bin/bash test:x:6099:5947::/home/test:/bin/bash Group Entries blake:x:100: blah:x:5511: test:x:8114: [duke 10] bmatheny > cpu --version CPU 1.4.1 Written by Blake Matheny Copyright 2001, 2002, 2003 Is it possible you entered the wrong password for the first one there? It works for me, is anyone else having this problem? What version are you using? -Blake Whatchu talkin' 'bout, Willis? > I am having problems when trying to set a user accounts password > interactively. > > root@llama /usr/local/src# cpu -w useradd -p test > Please enter the LDAP bind password: > Please enter desired user password: > > ldap: ldapOperation: ldap_bind_s: Invalid credentials (49) > ldap: CPU_init: Error in ldapOperation. > Something went wrong. Exiting. > root@llama /usr/local/src# gq & > [4] 11748 > root@llama /usr/local/src# cpu -w useradd -ptest test > Please enter the LDAP bind password: > User test successfully added! > root@llama /usr/local/src# > > Any ideas? > > Terrence > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Cpu-users mailing list > Cpu...@li... > https://lists.sourceforge.net/lists/listinfo/cpu-users -- Blake Matheny "... one of the main causes of the fall of the bma...@pu... Roman Empire was that, lacking zero, they had http://www.mkfifo.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
|
From: Eric A. <and...@ce...> - 2003-09-24 22:11:21
|
Blake Matheny wrote: >In cpu.conf, change RANDOM = "false" to RANDOM = "true". You will no longer >get a linear search for IDs (e.g. if the next unused ID is X you will most >likely not get to use X) but it will drop that time significantly. If you >notice in the log below, it is doing a linear search hitting 5537, 5538, >5539.... until an unused ID is found. Change RANDOM to true will hit an >unused ID quickly as a seeded rand() is used to generate an integer value >between MAX_UIDNUMBER and MIN_UIDNUMBER. > >You could also change MIN_UIDNUMBER/MIN_GIDNUMBER to a number higher than the >largest number in your directory, but this probably is not a good way to fix >things. > >In the future, CPU will probably need to cache the last number used for a >linear search, and start from that position the next time a useradd/groupadd >takes place. > > Why not make the search algorithm smarter? A binary search might be faster, or even a different kind of search. I haven't looked at the code, but shouldn't it be fast anyhow if the MIN_UIDNUMBER is set to the current highest UID? Unless you are adding 10000 users, shouldn't it stay fast? Also, if it is doing an ldap search for each uid it has to check, why not do the search for, say, 10 uids at a time, and then just parse through those 10? Anyway, just ideas.. Ignore if you like.. :) Eric -- ------------------------------------------------------------------ Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. ------------------------------------------------------------------ |
|
From: Terrence M. <tm...@ph...> - 2003-09-24 21:16:01
|
I am having problems when trying to set a user accounts password interactively. root@llama /usr/local/src# cpu -w useradd -p test Please enter the LDAP bind password: Please enter desired user password: ldap: ldapOperation: ldap_bind_s: Invalid credentials (49) ldap: CPU_init: Error in ldapOperation. Something went wrong. Exiting. root@llama /usr/local/src# gq & [4] 11748 root@llama /usr/local/src# cpu -w useradd -ptest test Please enter the LDAP bind password: User test successfully added! root@llama /usr/local/src# Any ideas? Terrence |
|
From: Blake M. <bma...@pu...> - 2003-09-24 21:01:09
|
In cpu.conf, change RANDOM = "false" to RANDOM = "true". You will no longer get a linear search for IDs (e.g. if the next unused ID is X you will most likely not get to use X) but it will drop that time significantly. If you notice in the log below, it is doing a linear search hitting 5537, 5538, 5539.... until an unused ID is found. Change RANDOM to true will hit an unused ID quickly as a seeded rand() is used to generate an integer value between MAX_UIDNUMBER and MIN_UIDNUMBER. You could also change MIN_UIDNUMBER/MIN_GIDNUMBER to a number higher than the largest number in your directory, but this probably is not a good way to fix things. In the future, CPU will probably need to cache the last number used for a linear search, and start from that position the next time a useradd/groupadd takes place. Let me know if that fixes things. -Blake Whatchu talkin' 'bout, Willis? > I am noticing that when adding new users the command take a considerable > amount of time to come back. Presumably this is as the result of > searching for unused gid or uid. > > From my slapd log. > > Sep 24 13:21:01 llama slapd[2434]: conn=1630 op=1062 SRCH attr=gidNumber > Sep 24 13:21:01 llama slapd[2434]: conn=1630 op=1062 SEARCH RESULT > tag=101 err=0 nentries=1 text= > Sep 24 13:21:01 llama slapd[2443]: conn=1630 op=1063 SRCH > base="ou=Group,dc..." scope=2 filter="(gidNumber=5537)" > Sep 24 13:21:01 llama slapd[2443]: conn=1630 op=1063 SRCH attr=gidNumber > Sep 24 13:21:01 llama slapd[2443]: conn=1630 op=1063 SEARCH RESULT > tag=101 err=0 nentries=1 text= > Sep 24 13:21:01 llama slapd[4906]: conn=1630 op=1064 SRCH > base="ou=Group,dc..." scope=2 filter="(gidNumber=5538)" > > It can take 30 seconds to add a users and moments to delete one. Is > there anyway to speed this up? Either via some additional indexing in > OpenLDAP or changes to the config file for cpu? > > I do not necessarily need to re-use user ids as my number of users is > only in the hundreds range. As a note I start at 5000. > > Terrence > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Cpu-users mailing list > Cpu...@li... > https://lists.sourceforge.net/lists/listinfo/cpu-users -- Blake Matheny "... one of the main causes of the fall of the bma...@pu... Roman Empire was that, lacking zero, they had http://www.mkfifo.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
|
From: Terrence M. <tm...@ph...> - 2003-09-24 20:29:32
|
I am noticing that when adding new users the command take a considerable amount of time to come back. Presumably this is as the result of searching for unused gid or uid. From my slapd log. Sep 24 13:21:01 llama slapd[2434]: conn=1630 op=1062 SRCH attr=gidNumber Sep 24 13:21:01 llama slapd[2434]: conn=1630 op=1062 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 24 13:21:01 llama slapd[2443]: conn=1630 op=1063 SRCH base="ou=Group,dc..." scope=2 filter="(gidNumber=5537)" Sep 24 13:21:01 llama slapd[2443]: conn=1630 op=1063 SRCH attr=gidNumber Sep 24 13:21:01 llama slapd[2443]: conn=1630 op=1063 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 24 13:21:01 llama slapd[4906]: conn=1630 op=1064 SRCH base="ou=Group,dc..." scope=2 filter="(gidNumber=5538)" It can take 30 seconds to add a users and moments to delete one. Is there anyway to speed this up? Either via some additional indexing in OpenLDAP or changes to the config file for cpu? I do not necessarily need to re-use user ids as my number of users is only in the hundreds range. As a note I start at 5000. Terrence |
|
From: Blake M. <bma...@pu...> - 2003-09-23 16:40:46
|
Hey Everyone, I have repalced the 1.4.1 packages on the website with new ones. There was a three line patch needed to fix compilation for RedHat 7.3. If you are running RedHat 7.3 and use cpu, please grab the new packages. -Blake |
|
From: Eric A. <and...@ce...> - 2003-09-23 13:17:34
|
Hey everyone! I've just downloaded cpu and untarred it, built it on FreeBSD 5.1. I'm just sending this to the list so others trying to build on FreeBSD know that it works just fine. With openldap server installed (2.1.22), the configure fails like: ./configure --with-ldap checking where ldap development files are... "yes" checking for main in -llber... no checking for main in -lldap... no checking lber.h usability... no checking lber.h presence... no checking for lber.h... no configure: error: Could not find lber.h However, once I installed the CLIENT stuff for openldap (/usr/ports/net/openldap22-client), it works flawlessly and I'm playing with the tool now. Thanks for the good work! Eric -- ------------------------------------------------------------------ Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. ------------------------------------------------------------------ |
2 messages has been excluded from this view by a project administrator.
