cpu-users Mailing List for Change Password Utility (Page 5)
Brought to you by:
matheny
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: Paul S. <pa...@nf...> - 2003-04-25 09:53:08
|
Hi all, I've build new debian packages from scratch. I've also filed an ITP bug since I intent to maintain this package for the forseable future. I'm no official debian maintainer yet but intent to become one as soon as I can get my gpg key signed. Add to your sources.list to give it a try: deb http://debian.nfgd.net/debian unstable/ And please let me know of any issues you may have with the build or any objections to my intentions for becoming official debian maintainer for this package. regards, -- ________________________________________________________________ Paul Stevens mailto:pa...@nf... NET FACILITIES GROUP PGP: finger pa...@nf... The Netherlands________________________________http://www.nfg.nl |
From: Paul S. <pa...@nf...> - 2003-04-24 18:52:25
|
Hi Blake, Thanks for the speedy reply. I've done some more testing. Blake Matheny wrote: > What happens when you specify the user base with -U at the command line? It lists the users just fine. Great. The grouplist is empty though. Bummer. I've also tried specifying the groupbase as well. I get: slapd[14168]: conn=754 op=0 BIND dn="DC=NFG,DC=NL" method=128 slapd[14168]: conn=754 op=0 RESULT tag=97 err=0 text= slapd[14170]: conn=754 op=1 SRCH base="ou=People,dc=nfg,dc=nl" scope=2 filter="(objectClass=posixAccount)" slapd[14170]: conn=754 op=1 SEARCH RESULT tag=101 err=0 text= slapd[13654]: conn=754 op=2 SRCH base="ou=People,dc=nfg,dc=nl" scope=2 filter="(objectClass=posixGroup)" slapd[13654]: conn=754 op=2 SEARCH RESULT tag=101 err=0 text= slapd[13532]: conn=-1 fd=17 closed Mmm, looks like -B is ignored and the -U optvalue is used for the groupbase. Let try. Yep, when I specify -U <groupbase> I do get the groups but an empty userlist. But when I do -B <groupbase> I get an ldap_search_st: no such object error. Looks like my build is seriously broken when it comes to reading the config. Lets run a strace.... Ah problem solved, bug located :-) The machine I was testing this on didn't have a BASE defined in /etc/ldap/ldap.conf. Defining the BASE makes cpu work as far as I can tell. I never ran into this one before because pam-ldap and nss-ldap worked just fine. > > -Blake > > Paul Stevens wrote: > >> >> Hi all, >> >> I've compiled and installed 1.3.99a >> >> I think I have it configured correctly but I keep getting >> >> #> cpu cat >> ldap: ldapCat: ldap_search_st: No such object (32) >> ldap: CPU_init: Error in ldapOperation. >> #> >> >> Setting the debug level on my ldap server reveals: >> >> slapd[13539]: conn=113 op=0 BIND dn="DC=NFG,DC=NL" method=128 >> slapd[13539]: conn=113 op=0 RESULT tag=97 err=0 text= >> slapd[13654]: conn=113 op=1 SRCH base="" scope=2 >> filter="(objectClass=posixAccount)" >> slapd[13654]: conn=113 op=1 RESULT tag=101 err=32 text= >> slapd[13532]: conn=-1 fd=9 closed >> >> even though I've set cpu.conf to read: >> >> BIND_DN = dc=nfg,dc=nl >> BIND_PASS = xxxxxxx >> USER_BASE = ou=People,dc=nfg,dc=nl >> GROUP_BASE = ou=Groups,dc=nfg,dc=nl >> USER_OBJECT_CLASS = posixAccount,shadowAccount,top >> GROUP_OBJECT_CLASS = posixGroup,top >> USER_FILTER = (objectClass=posixAccount) >> GROUP_FILTER = (objectClass=posixGroup) >> CN_STRING = cn >> >> Running >> >> ldapsearch -D dc=nfg,dc=nl -x -w xxxxxxx -b ou=People,dc=nfg,dc=nl >> '(objectClass=posixAccount)' >> >> works just fine though. >> >> So why doesn't cpu sent the correct basedn ? >> >> >> > > -- ________________________________________________________________ Paul Stevens mailto:pa...@nf... NET FACILITIES GROUP PGP: finger pa...@nf... The Netherlands________________________________http://www.nfg.nl |
From: Blake M. <bma...@pu...> - 2003-04-24 15:14:57
|
What happens when you specify the user base with -U at the command line? -Blake Paul Stevens wrote: > > Hi all, > > I've compiled and installed 1.3.99a > > I think I have it configured correctly but I keep getting > > #> cpu cat > ldap: ldapCat: ldap_search_st: No such object (32) > ldap: CPU_init: Error in ldapOperation. > #> > > Setting the debug level on my ldap server reveals: > > slapd[13539]: conn=113 op=0 BIND dn="DC=NFG,DC=NL" method=128 > slapd[13539]: conn=113 op=0 RESULT tag=97 err=0 text= > slapd[13654]: conn=113 op=1 SRCH base="" scope=2 > filter="(objectClass=posixAccount)" > slapd[13654]: conn=113 op=1 RESULT tag=101 err=32 text= > slapd[13532]: conn=-1 fd=9 closed > > even though I've set cpu.conf to read: > > BIND_DN = dc=nfg,dc=nl > BIND_PASS = xxxxxxx > USER_BASE = ou=People,dc=nfg,dc=nl > GROUP_BASE = ou=Groups,dc=nfg,dc=nl > USER_OBJECT_CLASS = posixAccount,shadowAccount,top > GROUP_OBJECT_CLASS = posixGroup,top > USER_FILTER = (objectClass=posixAccount) > GROUP_FILTER = (objectClass=posixGroup) > CN_STRING = cn > > Running > > ldapsearch -D dc=nfg,dc=nl -x -w xxxxxxx -b ou=People,dc=nfg,dc=nl > '(objectClass=posixAccount)' > > works just fine though. > > So why doesn't cpu sent the correct basedn ? > > > |
From: Paul S. <pa...@nf...> - 2003-04-24 14:59:35
|
Hi all, I've compiled and installed 1.3.99a I think I have it configured correctly but I keep getting #> cpu cat ldap: ldapCat: ldap_search_st: No such object (32) ldap: CPU_init: Error in ldapOperation. #> Setting the debug level on my ldap server reveals: slapd[13539]: conn=113 op=0 BIND dn="DC=NFG,DC=NL" method=128 slapd[13539]: conn=113 op=0 RESULT tag=97 err=0 text= slapd[13654]: conn=113 op=1 SRCH base="" scope=2 filter="(objectClass=posixAccount)" slapd[13654]: conn=113 op=1 RESULT tag=101 err=32 text= slapd[13532]: conn=-1 fd=9 closed even though I've set cpu.conf to read: BIND_DN = dc=nfg,dc=nl BIND_PASS = xxxxxxx USER_BASE = ou=People,dc=nfg,dc=nl GROUP_BASE = ou=Groups,dc=nfg,dc=nl USER_OBJECT_CLASS = posixAccount,shadowAccount,top GROUP_OBJECT_CLASS = posixGroup,top USER_FILTER = (objectClass=posixAccount) GROUP_FILTER = (objectClass=posixGroup) CN_STRING = cn Running ldapsearch -D dc=nfg,dc=nl -x -w xxxxxxx -b ou=People,dc=nfg,dc=nl '(objectClass=posixAccount)' works just fine though. So why doesn't cpu sent the correct basedn ? -- ________________________________________________________________ Paul Stevens mailto:pa...@nf... NET FACILITIES GROUP PGP: finger pa...@nf... The Netherlands________________________________http://www.nfg.nl |
From: Blake M. <bma...@pu...> - 2003-04-09 19:46:53
|
When you compile cpu, you need to specify what modules you would like to compile. In your case, you would want to do the following: ./configure --with-ldap <any other options> in order to compile the LDAP module. A couple of people have had issues with this, so I'll probably just do autodetection in the future (if at configure time we can find the libldap* libraries, we'll compile the ldap module, etc.). -Blake sup...@su... wrote: > This is an old problem I had written to you about awhile ago. I haven't > had time to play with it since until today. I'm still getting these > errors after cheching my /etc/ld.so.conf and running ldconfig. When I > list the contents of /usr/local/lib, I notice the file in question does > not even exist. Here is the output: > > dually:/stuff/cpu-1.3.99a# cpu > CPU_loadLibrary: dlopen(libcpu_ldap.so, RTLD_NOW) failed. > CPU_loadLibrary: libcpu_ldap.so: cannot open shared object file: No such > file or directory > There was an error loading the ldap library. Exiting. > dually:/stuff/cpu-1.3.99a# ls /usr/local/lib > libcputil.a libdb.so libldap.so.2.0.111 > libcputil.la liblber.a libldap_r.a > libcputil.so liblber.la libldap_r.la > libcputil.so.0 liblber.so libldap_r.so > libcputil.so.0.0.0 liblber.so.2 libldap_r.so.2 > libdb-4.0.a liblber.so.2.0.111 libldap_r.so.2.0.111 > libdb-4.0.la libldap.a php.ini > libdb-4.0.so libldap.la python2.1 > libdb-4.so libldap.so site_ruby > libdb.a libldap.so.2 > dually:/stuff/cpu-1.3.99a# > > Any more suggestions? > > Ben > > >>It looks like your email client has a bug. It is setting mimetype to >>$email_type which standard mail clients won't know about. In any case, >>CPU uses dynamically loadable libraries for various reasons. You will >>need to do one of two things: >> >>a.) Set LD_LIBRARY_PATH environmental variable to the library path. For >> instance if you installed cpu in /usr/local/bin for the bash shell >>you would do: export LD_LIBRARY_PATH=/usr/local/lib. This is >>appropriate when you have installed it in your home directory (in >>which case >> LD_LIBRARY_PATH would be set to $HOME/lib) >>b.) If it is installed system wide, edit your /etc/ld.so.conf file and >>make >> sure that /usr/local/lib (or wherever the cpu libs are installed). >>You will then need to run 'ldconfig' to add the libraries to the >>system cache >> >>The looks of below tell me it is installed system wide, in which case if >>you simply did a './configure --with-ldap && make && make install' just >>running ldconfig should be adequate, assuming that "/usr/local/lib" is >>already in your /etc/ld.so.conf file. This is a pretty common error >>(unfortunately) when using loadable libraries, I'll have to put a hack >>in so that the install location is automatically added to the search >>path of the dl() calls. >> >>-Blake >> >>Whatchu talkin' 'bout, Willis? >> >>>My apologies on the email formatting. I've turned of HTML formatting >>>so this should look nicer. >>> >>>Anyhow, I've successfully compiled and installed CPU, but now get the >>>following when I simply enter in the command 'cpu' (no arguments): >>> >>>dually:~# cpu >>>CPU_loadLibrary: dlopen(libcpu_ldap.so, RTLD_NOW) failed. >>>CPU_loadLibrary: libcpu_ldap.so: cannot open shared object file: No >>>such file or directory >>>There was an error loading the ldap library. Exiting. >>>dually:~# >>> >>>Any ideas? >>> >>>Ben >> >>-- >>Blake Matheny "... one of the main causes of the fall of the >>bma...@pu... Roman Empire was that, lacking zero, they had >>http://www.dbaseiv.net no way to indicate successful termination of >>http://ovmj.org/GNUnet/ their C programs." --Robert Firth >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by:Crypto Challenge is now open! >>Get cracking and register here for some mind boggling fun and >>the chance of winning an Apple iPod: >>http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en >>_______________________________________________ >>Cpu-users mailing list >>Cpu...@li... >>https://lists.sourceforge.net/lists/listinfo/cpu-users > > > > |
From: <sup...@su...> - 2003-04-09 14:00:39
|
This is an old problem I had written to you about awhile ago. I haven't had time to play with it since until today. I'm still getting these errors after cheching my /etc/ld.so.conf and running ldconfig. When I list the contents of /usr/local/lib, I notice the file in question does not even exist. Here is the output: dually:/stuff/cpu-1.3.99a# cpu CPU_loadLibrary: dlopen(libcpu_ldap.so, RTLD_NOW) failed. CPU_loadLibrary: libcpu_ldap.so: cannot open shared object file: No such file or directory There was an error loading the ldap library. Exiting. dually:/stuff/cpu-1.3.99a# ls /usr/local/lib libcputil.a libdb.so libldap.so.2.0.111 libcputil.la liblber.a libldap_r.a libcputil.so liblber.la libldap_r.la libcputil.so.0 liblber.so libldap_r.so libcputil.so.0.0.0 liblber.so.2 libldap_r.so.2 libdb-4.0.a liblber.so.2.0.111 libldap_r.so.2.0.111 libdb-4.0.la libldap.a php.ini libdb-4.0.so libldap.la python2.1 libdb-4.so libldap.so site_ruby libdb.a libldap.so.2 dually:/stuff/cpu-1.3.99a# Any more suggestions? Ben > It looks like your email client has a bug. It is setting mimetype to > $email_type which standard mail clients won't know about. In any case, > CPU uses dynamically loadable libraries for various reasons. You will > need to do one of two things: > > a.) Set LD_LIBRARY_PATH environmental variable to the library path. For > instance if you installed cpu in /usr/local/bin for the bash shell > you would do: export LD_LIBRARY_PATH=/usr/local/lib. This is > appropriate when you have installed it in your home directory (in > which case > LD_LIBRARY_PATH would be set to $HOME/lib) > b.) If it is installed system wide, edit your /etc/ld.so.conf file and > make > sure that /usr/local/lib (or wherever the cpu libs are installed). > You will then need to run 'ldconfig' to add the libraries to the > system cache > > The looks of below tell me it is installed system wide, in which case if > you simply did a './configure --with-ldap && make && make install' just > running ldconfig should be adequate, assuming that "/usr/local/lib" is > already in your /etc/ld.so.conf file. This is a pretty common error > (unfortunately) when using loadable libraries, I'll have to put a hack > in so that the install location is automatically added to the search > path of the dl() calls. > > -Blake > > Whatchu talkin' 'bout, Willis? >> My apologies on the email formatting. I've turned of HTML formatting >> so this should look nicer. >> >> Anyhow, I've successfully compiled and installed CPU, but now get the >> following when I simply enter in the command 'cpu' (no arguments): >> >> dually:~# cpu >> CPU_loadLibrary: dlopen(libcpu_ldap.so, RTLD_NOW) failed. >> CPU_loadLibrary: libcpu_ldap.so: cannot open shared object file: No >> such file or directory >> There was an error loading the ldap library. Exiting. >> dually:~# >> >> Any ideas? >> >> Ben > > -- > Blake Matheny "... one of the main causes of the fall of the > bma...@pu... Roman Empire was that, lacking zero, they had > http://www.dbaseiv.net no way to indicate successful termination of > http://ovmj.org/GNUnet/ their C programs." --Robert Firth > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Cpu-users mailing list > Cpu...@li... > https://lists.sourceforge.net/lists/listinfo/cpu-users |
From: Blake M. <bma...@pu...> - 2003-03-31 21:31:04
|
Someone had posted the following: ------------------------------------------------------------- My network uses LDAP with krb5 passwords such that the password entry in ldap is {KERBEROS}princ@REALM Glancing at cpu, the ldap plugin can't quite support this, and it would still require me to add a principle with a second command. However, only one plugin is allowed. Would it be preferable (if I ever get the time, so probably not) for an altered ldap to allow for this setup and create the entry (ldap-krb5 module) or a restructure to allow a user module and a password module? ------------------------------------------------------------- I added code to CVS that allows the following: If you specify a hash (-H hashname) where hashname is unknown to CPU, the default behavior is to add the following value for the userPassword attribute: hashnamecleartextpass. So to accomplish the above request, someone would do cpu useradd -H \{KERBEROS\} -pprinc@REALM That should allow people to deal with some other schemes. Also, I never got any feedback on the -a switch, for specifying a file with additional attributes. If I don't get any bug reports in a few more days, I'm probably going to put out a new version. Thanks. -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.dbaseiv.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
From: Blake M. <bma...@pu...> - 2003-03-11 22:22:31
|
It looks like your email client has a bug. It is setting mimetype to $email_type which standard mail clients won't know about. In any case, CPU uses dynamically loadable libraries for various reasons. You will need to do one of two things: a.) Set LD_LIBRARY_PATH environmental variable to the library path. For instance if you installed cpu in /usr/local/bin for the bash shell you would do: export LD_LIBRARY_PATH=/usr/local/lib. This is appropriate when you have installed it in your home directory (in which case LD_LIBRARY_PATH would be set to $HOME/lib) b.) If it is installed system wide, edit your /etc/ld.so.conf file and make sure that /usr/local/lib (or wherever the cpu libs are installed). You will then need to run 'ldconfig' to add the libraries to the system cache The looks of below tell me it is installed system wide, in which case if you simply did a './configure --with-ldap && make && make install' just running ldconfig should be adequate, assuming that "/usr/local/lib" is already in your /etc/ld.so.conf file. This is a pretty common error (unfortunately) when using loadable libraries, I'll have to put a hack in so that the install location is automatically added to the search path of the dl() calls. -Blake Whatchu talkin' 'bout, Willis? > My apologies on the email formatting. I've turned of HTML formatting so > this should look nicer. > > Anyhow, I've successfully compiled and installed CPU, but now get the > following when I simply enter in the command 'cpu' (no arguments): > > dually:~# cpu > CPU_loadLibrary: dlopen(libcpu_ldap.so, RTLD_NOW) failed. > CPU_loadLibrary: libcpu_ldap.so: cannot open shared object file: No such > file or directory > There was an error loading the ldap library. Exiting. > dually:~# > > Any ideas? > > Ben -- Blake Matheny "... one of the main causes of the fall of the bma...@pu... Roman Empire was that, lacking zero, they had http://www.dbaseiv.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
From: <sup...@su...> - 2003-03-11 17:01:02
|
My apologies on the email formatting. I've turned of HTML formatting so this should look nicer. Anyhow, I've successfully compiled and installed CPU, but now get the following when I simply enter in the command 'cpu' (no arguments): dually:~# cpu CPU_loadLibrary: dlopen(libcpu_ldap.so, RTLD_NOW) failed. CPU_loadLibrary: libcpu_ldap.so: cannot open shared object file: No such file or directory There was an error loading the ldap library. Exiting. dually:~# Any ideas? Ben > Hi Ben, > I forgot to add parser.h as an EXTRA_SOURCE for make dist. This has been > fixed, you can now grab a new tarball from sourceforge. In addition, the > body of your emails are arriving as an attachment, which is rather > annoying :-) > > -Blake > > Whatchu talkin' 'bout, Willis? >> I keep getting the following errors when trying to compile the latest >> 1.3.99a version of CPU. My system is a Debian Woody 3.0 and I'm doing >> a default configure and make (no flags or options). >> >> parser.c:35: util/parser.h: No such file or directory >> make[3]: *** [parser.lo] Error 1 >> make[3]: Leaving directory `/stuff/cpu-1.3.99a/src/util' >> make[2]: *** [all-recursive] Error 1 >> make[2]: Leaving directory `/stuff/cpu-1.3.99a/src/util' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory `/stuff/cpu-1.3.99a/src' >> make: *** [all-recursive] Error 1 >> >> >> Ben > > > -- > Blake Matheny "... one of the main causes of the fall of the > bma...@pu... Roman Empire was that, lacking zero, they had > http://www.dbaseiv.net no way to indicate successful termination of > http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
From: Blake M. <bma...@pu...> - 2003-03-10 18:44:37
|
Hi Ben, I forgot to add parser.h as an EXTRA_SOURCE for make dist. This has been fixed, you can now grab a new tarball from sourceforge. In addition, the body of your emails are arriving as an attachment, which is rather annoying :-) -Blake Whatchu talkin' 'bout, Willis? > I keep getting the following errors when trying to compile the latest > 1.3.99a version of CPU. My system is a Debian Woody 3.0 and I'm doing a > default configure and make (no flags or options). > > parser.c:35: util/parser.h: No such file or directory > make[3]: *** [parser.lo] Error 1 > make[3]: Leaving directory `/stuff/cpu-1.3.99a/src/util' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/stuff/cpu-1.3.99a/src/util' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/stuff/cpu-1.3.99a/src' > make: *** [all-recursive] Error 1 > > > Ben -- Blake Matheny "... one of the main causes of the fall of the bma...@pu... Roman Empire was that, lacking zero, they had http://www.dbaseiv.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
From: <sup...@su...> - 2003-03-10 18:32:14
|
I keep getting the following errors when trying to compile the latest 1.3.99a version of CPU. My system is a Debian Woody 3.0 and I'm doing a default configure and make (no flags or options). parser.c:35: util/parser.h: No such file or directory make[3]: *** [parser.lo] Error 1 make[3]: Leaving directory `/stuff/cpu-1.3.99a/src/util' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/stuff/cpu-1.3.99a/src/util' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/stuff/cpu-1.3.99a/src' make: *** [all-recursive] Error 1 Ben |
From: Blake M. <bma...@pu...> - 2003-03-09 20:26:30
|
Hello All, I have put cpu-1.3.99a up in the form of a couple of source tarballs which are available from here: http://sourceforge.net/project/showfiles.php?group_id=45948 Please submit any bug reports to the list. This release is mostly bug fixes (thanks John Dalbec and others) and some fufilled feature requests. * You can now add arbitrary attributes in LDAP (specifying -a with an ldif file) * You can now specify the group name or the group id when adding users Those are the big features, a couple of others. Enjoy. -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.dbaseiv.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
From: <sup...@su...> - 2003-02-25 18:06:16
|
I can't tell you enough how nice a utility this is! Any idea when the next version is expected out with some of these additional features? Using cpu as a template & useradd utility would be such an amazing timesaver!<BR><BR>Keep up the fantastic work!<BR>Ben<BR><BR>> Hi Ben,<BR>> Unfortunately at this point CPU only allows you to add attributes that<BR>> are specified by RFC2307 (and a few that aren't). Attributes that you<BR>> can add include: uid, userPassword, uidNumber, gidNumber, gecos,<BR>> homeDirectory, loginShell, shadowLastChange, shadowMin, shadowMax,<BR>> shadowWarning, shadowInactive, shadowExpire, shadowFlag, sn (Surname),<BR>> givenName and Mail.<BR>> <BR>> The three that are not included in RFC2307 are sn, givenName, and mail.<BR>> It would be pretty easy to allow people to write ldif's that could be<BR>> included with the attributes that CPU already handles. I think this is<BR>> neccesary, so I'll look into it. I imagine some of this will be handled<BR>> in the next version of CPU.<BR>> <BR>> -Blake<BR>> <BR>> Whatchu talkin' 'bout, Willis?<BR>>> Is it possible to configure cpu to add other attributes with defualts<BR>>> to a new user entry? I would like to build as much of the<BR>>> "skeleton" of my LDAP entry with the single cpu command rather than<BR>>> making the user and then adding to the entry later.<BR>>><BR>>> Ben<BR>> <BR>> -- <BR>> Blake Matheny "... one of the main causes of the fall of the<BR>> bma...@pu... Roman Empire was that, lacking zero, they had<BR>> http://www.dbaseiv.net no way to indicate successful termination of<BR>> http://ovmj.org/GNUnet/ their C programs." --Robert Firth<BR> |
From: Blake M. <bma...@pu...> - 2003-02-24 20:58:16
|
Hi Ben, Unfortunately at this point CPU only allows you to add attributes that are specified by RFC2307 (and a few that aren't). Attributes that you can add include: uid, userPassword, uidNumber, gidNumber, gecos, homeDirectory, loginShell, shadowLastChange, shadowMin, shadowMax, shadowWarning, shadowInactive, shadowExpire, shadowFlag, sn (Surname), givenName and Mail. The three that are not included in RFC2307 are sn, givenName, and mail. It would be pretty easy to allow people to write ldif's that could be included with the attributes that CPU already handles. I think this is neccesary, so I'll look into it. I imagine some of this will be handled in the next version of CPU. -Blake Whatchu talkin' 'bout, Willis? > Is it possible to configure cpu to add other attributes with defualts to a > new user entry? I would like to build as much of the "skeleton" of > my LDAP entry with the single cpu command rather than making the user and > then adding to the entry later. > > Ben -- Blake Matheny "... one of the main causes of the fall of the bma...@pu... Roman Empire was that, lacking zero, they had http://www.dbaseiv.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
From: <sup...@su...> - 2003-02-24 20:35:35
|
Is it possible to configure cpu to add other attributes with defualts to a new user entry? I would like to build as much of the "skeleton" of my LDAP entry with the single cpu command rather than making the user and then adding to the entry later.<BR><BR>Ben |
From: Blake M. <bma...@pu...> - 2003-02-17 23:59:27
|
Hello All, I have put cpu-1.3.99 up in the form of a couple of source tarballs which are available from here: http://sourceforge.net/project/showfiles.php?group_id=45948&release_id=140949 Please submit any bug reports to the list. This release marks a significant change from CPU-1.3.13, which was released almost a year ago. Some features that have been added include: * Rewritten completely, nearly no original code is still in this version * Optional random password generation * Optional cracklib password checking * Cat now displays groups as well as users * Modular code makes bug hunting easy * Almost 100% command line compatibility with traditional user and group administration utilities * If you specify the -G group1,group2... option on a useradd, CPU will search for those groups in the directory and add the user to those groups Many more new features as well. If people don't submit too many bug reports I will likely release a 1.4.0 version soon. Thanks and enjoy! -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.dbaseiv.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
From: Blake M. <ma...@db...> - 2003-02-16 22:56:53
|
Hello Everyone, This weekend I got the following items completed on the todo list: * All group functions now work * Usermod is finished * Configuration file options are documented * File functionality all works now New features: * Cat now displays groups and users * CPU now supports the _exact_ same options as user{add,mod,del} and group{add,mod,del}. There are a few command line options that are not yet supported, but they will be in the future * CPU command line behavior has now changed to be much more like the user,group{add,mod,del} programs * When you add a user as follows: cpu useradd -G wheel,root username CPU will go and search the directory for those groups, and add the users to them or warn you if the groups are not found Things left to do before I can get 1.4.0 out the door: * Some testing (feel free to help out :-)) * Get CPU working so you can specify a username and a unix style password file to get that users information from (only getting their shadow password currently works) * Look for FIXME and other comments in the sourcecode, and do that * Get the man pages rewritten * Be able to also administer flat files (write a plugin for it) The new sourcecode is not yet in CVS, but it will be early tomorrow morning, I'm -6 GMT. In any case, once I get the new code in I could really use some people testing it and making comments on things they would like to see. Thanks. -Blake -- Blake Matheny "... one of the main causes of the fall of the ma...@db... Roman Empire was that, lacking zero, they had http://www.dbaseiv.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
From: Blake M. <ma...@db...> - 2003-02-15 19:50:43
|
Hi Jean, first, did you run the bootstrap script? It will make sure that those files are created. Also, make sure that you have the appropriate versions of the autotools, as documented in the README file. -Blake Whatchu talkin' 'bout, Willis? > I want to try, your new version 1.3.99 but I have error with automake: > > configure.ac: required file `./install-sh' not found > configure.ac: required file `./mkinstalldirs' not found > configure.ac: required file `./missing' not found > configure.ac:4: required file `././src/include/config.h.in' not found > src/main/Makefile.am: required file `./depcomp' not found > > Thanks > -- > Jean Bel > > > ------------------------------------------------------- > 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 ma...@db... Roman Empire was that, lacking zero, they had http://www.dbaseiv.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
From: Blake M. <ma...@db...> - 2003-02-15 19:49:27
|
Run ./bootstrap to get everything configured. In the README file are instructions for compiling, including what versions of the autotools need to be installed. Keep in mind that you now _must_ run configure with ./configure --with-ldap to get the ldap plugin compiled. -Blake Whatchu talkin' 'bout, Willis? > >Date: Mon, 10 Feb 2003 15:21:06 -0500 > >From: Blake Matheny <bma...@pu...> > >To: cpu...@li... > >Subject: [Cpu-users] CPU 1.3.99 > > > >Hello List, > >I'm not actually sure if anyone is still on this or not :-) It's been > >almost a > >year since any fresh code has been written, but I refuse to let CPU become > >another abandoned free software project! Having said that, this weekend I > >tried to do something about it and completely rewrote CPU. It was a mess, > >and not something that I would have wanted to contribute to. The 'new' > >version > >is currently only available via cvs, under the directory 'cpu'. The TODO > >file > >has been included below. Please, if you can donate time or energy to help > >out, > >including testing, please do. Thanks. > > > >------------------------------------------------------------------------------ > >There is a lot to do in order to get CPU to a place where I can put it to > >rest > >for good. I decided to rewrite all of the code, which while this was a good > >idea, doing it in a weekend may not have been. As a result, there are a few > >bugs. > > > >I rewrote the system so that it would be more attractive for someone to > >pickup > >and continue to maintain. If you are interested (or will be after I finish > >with the fixes below) please contact me. > > > >Here are some of the features that CPU 1.3.99 has that previous versions > >did > >not, and some of the features that are still missing: > > > >New Features > >* Code is extremely modular, meaning people can write back-ends easily for > >any > > kind of system by just exporting CPU_init in their code. This also makes > > it > > easy for people to include code already written from other projects. > >* I'm not so embarrassed to have written it > >* New configuration file format allows multiple authentication methods to > >be > > used > >* Modular design allows you to specify which back-end to administer > >through a > > command line switch which will then load the appropriate module. All > > command > > line options are specific to the back-end you are administering > >* Some API functionality to encourage people to write some new back-ends. > >* Rewrote build system > > I couldn't get this to build without a src/include/config.h.in file. > Are there "developer" build instructions somewhere? Minimum toolchain > requirements? I did: > libtoolize > aclocal > autoconf > automake > ./configure > make > ...which died because "VERSION" wasn't defined. I fixed that, then it > died because "HAVE_BZERO" wasn't defined. I fixed that, and it built. > But now the LDAP plugins don't build. Is it because "HAVE_LDAP" isn't > set in automake? How do I set it? > Thanks, > John Dalbec > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > 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 ma...@db... Roman Empire was that, lacking zero, they had http://www.dbaseiv.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
From: Jean B. <su...@ma...> - 2003-02-15 19:16:51
|
I want to try, your new version 1.3.99 but I have error with automake: configure.ac: required file `./install-sh' not found configure.ac: required file `./mkinstalldirs' not found configure.ac: required file `./missing' not found configure.ac:4: required file `././src/include/config.h.in' not found src/main/Makefile.am: required file `./depcomp' not found Thanks --=20 Jean Bel |
From: John D. <jpd...@ys...> - 2003-02-14 22:27:27
|
> Date: Mon, 10 Feb 2003 15:21:06 -0500 > From: Blake Matheny <bma...@pu...> > To: cpu...@li... > Subject: [Cpu-users] CPU 1.3.99 > > Hello List, > I'm not actually sure if anyone is still on this or not :-) It's been almost a > year since any fresh code has been written, but I refuse to let CPU become > another abandoned free software project! Having said that, this weekend I > tried to do something about it and completely rewrote CPU. It was a mess, > and not something that I would have wanted to contribute to. The 'new' version > is currently only available via cvs, under the directory 'cpu'. The TODO file > has been included below. Please, if you can donate time or energy to help out, > including testing, please do. Thanks. > > ------------------------------------------------------------------------------ > There is a lot to do in order to get CPU to a place where I can put it to rest > for good. I decided to rewrite all of the code, which while this was a good > idea, doing it in a weekend may not have been. As a result, there are a few > bugs. > > I rewrote the system so that it would be more attractive for someone to pickup > and continue to maintain. If you are interested (or will be after I finish > with the fixes below) please contact me. > > Here are some of the features that CPU 1.3.99 has that previous versions did > not, and some of the features that are still missing: > > New Features > * Code is extremely modular, meaning people can write back-ends easily for any > kind of system by just exporting CPU_init in their code. This also makes it > easy for people to include code already written from other projects. > * I'm not so embarrassed to have written it > * New configuration file format allows multiple authentication methods to be > used > * Modular design allows you to specify which back-end to administer through a > command line switch which will then load the appropriate module. All command > line options are specific to the back-end you are administering > * Some API functionality to encourage people to write some new back-ends. > * Rewrote build system I couldn't get this to build without a src/include/config.h.in file. Are there "developer" build instructions somewhere? Minimum toolchain requirements? I did: libtoolize aclocal autoconf automake ./configure make ...which died because "VERSION" wasn't defined. I fixed that, then it died because "HAVE_BZERO" wasn't defined. I fixed that, and it built. But now the LDAP plugins don't build. Is it because "HAVE_LDAP" isn't set in automake? How do I set it? Thanks, John Dalbec |
From: Blake M. <bma...@pu...> - 2003-02-10 20:21:24
|
Hello List, I'm not actually sure if anyone is still on this or not :-) It's been almost a year since any fresh code has been written, but I refuse to let CPU become another abandoned free software project! Having said that, this weekend I tried to do something about it and completely rewrote CPU. It was a mess, and not something that I would have wanted to contribute to. The 'new' version is currently only available via cvs, under the directory 'cpu'. The TODO file has been included below. Please, if you can donate time or energy to help out, including testing, please do. Thanks. ------------------------------------------------------------------------------ There is a lot to do in order to get CPU to a place where I can put it to rest for good. I decided to rewrite all of the code, which while this was a good idea, doing it in a weekend may not have been. As a result, there are a few bugs. I rewrote the system so that it would be more attractive for someone to pickup and continue to maintain. If you are interested (or will be after I finish with the fixes below) please contact me. Here are some of the features that CPU 1.3.99 has that previous versions did not, and some of the features that are still missing: New Features * Code is extremely modular, meaning people can write back-ends easily for any kind of system by just exporting CPU_init in their code. This also makes it easy for people to include code already written from other projects. * I'm not so embarrassed to have written it * New configuration file format allows multiple authentication methods to be used * Modular design allows you to specify which back-end to administer through a command line switch which will then load the appropriate module. All command line options are specific to the back-end you are administering * Some API functionality to encourage people to write some new back-ends. * Rewrote build system * You can now choose whether to do a serial or random search for a new UID or GID as opposed to just random * We now strictly follow the RFC 2307 standards. However, CPU is still flexible enough that you can use other attributes * You can now decide whether to use uid or cn for your dn Things that don't work yet (that used to) * All group functions. Getting them going again will be trivial, all checking is already done by the time the appropriate functions get called. * Usermod function is only half funtional * New configuration file options aren't documented * Changes in command line arguments haven't been documented * No file functionality works (i.e. creating home directories, removing old directories, etc) * Bug checking Things that people want that I have promised * TLS/SSL for LDAP * Support Samba * XML files for adding weird users Problems I haven't yet figured out * Why our included version of getopt() seems to have some serious problems with multiple invocations * What does dmalloc suck so bad? It catches things that make no sense. Things I'm planning on adding for fun: * Support administration of flat files! * NT4 administration * The stuff that people listed above -- Blake Matheny "... one of the main causes of the fall of the bma...@pu... Roman Empire was that, lacking zero, they had http://www.dbaseiv.net no way to indicate successful termination of http://ovmj.org/GNUnet/ their C programs." --Robert Firth |
From: Odin K. <od...@io...> - 2002-08-13 23:02:48
|
hi everybuddy, i just wrote some scripts for cpu that mimic debians '{add|del}{user|group}' scripts with cpu. for me they do a good job, they may however require some debugging though. mail me with any questions or suggestions you might have you can download the scripts from http://io.philo.at/~odin/dl/cpu_wrap.tgz salut odin -- Die Wissenschaft und ihre Lehre ist frei und die Erde ist eine Scheibe! NEIN zum Universit?tsgesetz 2002 http://weltklasseuni.at/ |
From: John D. <jpd...@cc...> - 2002-06-26 18:58:58
|
Thorsten Kukuk wrote: > What I wish: > Better compatiblity with the useradd options from the shadow suite. > Especially I'm missing the -e and -G options and I have a problem > with the different meaning of the -f option. Of course "groupadd -f" has yet another meaning. I would like to see an option to set the cn independent of -F and -L. Among other reasons, some of my users are extremely attached to their middle names and/or titles such as "Dr.". Thanks, Dr. John Paul Dalbec ;-) |
From: Caylan V. L. <ca...@cs...> - 2002-06-21 22:15:52
|
Ok, I upgraded both packages: autoconf (GNU Autoconf) 2.53 Written by David J. MacKenzie and Akim Demaille. and automake (GNU automake) 1.6 Written by Tom Tromey <tr...@re...>. But when I run make: . . . checking for isascii... yes checking for memset... yes checking for mkdir... yes checking for strchr... yes checking for strdup... yes checking for strspn... yes checking your OS... linux configure: creating ./config.status cd . && \ CONFIG_HEADERS= CONFIG_LINKS= \ CONFIG_FILES=Makefile /bin/sh ./config.status config.status: creating Makefile Making all in src make[1]: Entering directory `/usr/local/src/source/cpu-1.3.13/src' cd .. && \ CONFIG_HEADERS= CONFIG_LINKS= \ CONFIG_FILES=src/Makefile /bin/sh ./config.status config.status: creating src/Makefile make[1]: Leaving directory `/usr/local/src/source/cpu-1.3.13/src' make[1]: Entering directory `/usr/local/src/source/cpu-1.3.13/src' Makefile:155: *** missing separator. Stop. make[1]: Leaving directory `/usr/local/src/source/cpu-1.3.13/src' make: *** [all-recursive] Error 1 Bad news bears! BTW: # echo $CPPFLAGS -I/usr/local/include # echo $LDFLAGS -L/usr/local/lib Any ideas/fixes? Thanks, Caylan Van Larson Unix Administrator - Systems Team Member University of North Dakota (Aerospace College) ca...@cs... 701-777-6151 (work) On Tue, 4 Jun 2002, Blake Matheny wrote: > Is it possible for you to upgrade to newer versions of > autoconf/automake? Currently cpu needs autoconf >= 2.52 and automake > >= 1.5. Other versions may work, but more likely is that you will get > results like you did. If it isn't possible let me know, I'll try and > figure something out. I know someone produced an rpm of cpu at some > point, try searching google. Thanks. > > -Blake > > >Whatchu talkin' 'bout, Willis? > > Yes sir, my appologies, > > > > This should aid you in aiding me ;D > > > > [root@slurpy source]# rpm -qa | grep auto > > autoconf-2.13-14 > > automake-1.4p5-2 > > autofs-3.1.7-21 > > [root@slurpy source]# rpm -qa | grep glib > > glib-devel-1.2.10-5 > > glibc-2.2.4-13 > > glibc-common-2.2.4-13 > > glib-1.2.10-5 > > glibc-devel-2.2.4-13 > > [root@slurpy source]# > > > > > > > > Caylan Van Larson > > Unix Administrator - Systems Team Member > > University of North Dakota (Aerospace College) > > ca...@cs... > > 701-777-6151 (work) > > > > On Tue, 4 Jun 2002, Blake Matheny wrote: > > > > > Could you please reply with the versions of autoconf and automake? > > > Thanks. > > > > > > -Blake > > > > > > Whatchu talkin' 'bout, Willis? > > > > Hello, > > > > > > > > Anyone know what is happening here? > > > > > > > > [root@slurpy cpu-1.3.13]# make > > > > cd . && /bin/sh /usr/local/src/source/cpu-1.3.13/missing --run aclocal > > > > cd . && \ > > > > /bin/sh /usr/local/src/source/cpu-1.3.13/missing --run automake --gnu > > > > Makefile > > > > cd . && /bin/sh /usr/local/src/source/cpu-1.3.13/missing --run autoconf > > > > autoconf: Undefined macros: > > > > configure.in:51:AC_FUNC_CHOWN > > > > configure.in:52:AC_FUNC_MALLOC > > > > configure.in:53:AC_FUNC_STAT > > > > WARNING: `autoconf' is missing on your system. You should only need it if > > > > you modified `configure.in'. You might want to install the > > > > `Autoconf' and `GNU m4' packages. Grab them from any GNU > > > > archive site. > > > > /bin/sh ./config.status --recheck > > > > running /bin/sh ./configure --no-create --no-recursion > > > > configure: error: can not find sources in . or .. > > > > make: *** [config.status] Error 1 > > > > > > > > > > > > I have tried: > > > > ./configure > > > > ./configure --with-ldap=/usr/local/lib > > > > ./configure --with-ldap=/usr/local > > > > > > > > All to no good compliation, > > > > > > > > Thank you very much, > > > > > > > > > > > > Caylan Van Larson > > > > Unix Administrator - Systems Team Member > > > > University of North Dakota (Aerospace College) > > > > ca...@cs... > > > > 701-777-6151 (work) > > > > > > > > > > > > _______________________________________________________________ > > > > > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > > > > > _______________________________________________ > > > > Cpu-users mailing list > > > > Cpu...@li... > > > > https://lists.sourceforge.net/lists/listinfo/cpu-users > > > > > > -- > > > Blake Matheny > > > ma...@db... > > > http://www.dbaseiv.net > > > > > > > > > _______________________________________________________________ > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > _______________________________________________ > > Cpu-users mailing list > > Cpu...@li... > > https://lists.sourceforge.net/lists/listinfo/cpu-users > > -- > Blake Matheny > ma...@db... > http://www.dbaseiv.net > |