Recent changes to bugs

CPU doesn't increment through large GID numbers properly

2009-09-03T18:45:02Z

We have a weird GID setup....
Some system groups in the 0-1000 range.
Users primary groups in the 60-80000 range.
One off groups in the 9000000-910000.
I have no idea why it was setup like this.

Anyhow, if MAX_GIDNUMBER and MIN_GIDNUMBER are in any of those ranges, but the last one, with RANDOM set to false when doing a "cpu groupadd foo -w" it will find the first free GID and do its thing like it should.

However, if my cpu.conf looks like this
MAX_GIDNUMBER = 9100000
MIN_GIDNUMBER = 9000040
it will create groups with GIDs in the 10000 range.

Any thoughts on why it doesn't handle numbers this large?

Using 1.4.3 on Cent OS 5.3 btw.
Let me know if you need to know anything else.

Segfault on Solaris

2007-03-29T08:05:37Z

> uname -a
SunOS 5.10 Generic_118844-26 i86pc i386 i86pc

> cc -V
cc: Sun C 5.7 Patch 117837-04 2005/05/11

> CC=cc ./configure --with-ldap=/opt/csw
...
config successful

> make; make install
...
success

> cpu cat
Segmentation Fault (core dumped)

The config.log is attached to this message

(gcc produced the same result)

compilation is failed on FreeBSD

2007-03-27T13:31:26Z

FreeBSD 6.2

gcc version 3.4.6 [FreeBSD] 20060305

> cd cpu-1.4.3
> ./configure --with-ldap=/usr/local
> make
ld.c: In function `getlGid':
ld.c:806: error: subscripted value is neither array nor pointer

and the following patch makes all things fine:

--- ld.c.orig Tue Mar 27 17:14:05 2007
+++ ld.c Tue Mar 27 15:15:41 2007
@@ -771,6 +771,7 @@
NULL
};
char *gid = NULL;
+ char **gid_ = NULL;

cn = cfg_get_str ("LDAP", "GROUP_CN_STRING");
if (cn == NULL)
@@ -803,9 +804,9 @@
return -10;
if (gid != NULL)
{
- gid = ldap_get_values (ld, pos, gid)[0];
- if (gid != NULL)
- return atoi (gid);
+ gid_ = ldap_get_values (ld, pos, gid);
+ if (gid_ != NULL && gid_[0] != NULL)
+ return atoi (gid_[0]);
else
return -10;
}

compilation fix for fedora 6 (maybe earlier)

2006-12-18T16:27:24Z

This is a change that was necessary to get CPU to compile under fedora core 6. I seem to recall that I also had to apply it to an earlier fedora release, but don't recall the details.

In src/plugins/ldap/commandline.c around line 86 there is the following line:

(int) passent->sp_lstchg = passent->sp_min = passent->sp_max = -10;

which results in "commandline.c:86: error: invalid lvalue in assignment"

Changing it to be the following fixed the problem:

passent->sp_lstchg = -10;
passent->sp_min = -10;
passent->sp_max = -10;

error cpu useradd

2006-10-14T18:23:31Z

I get an error when i want to add a user
cpu useradd -g users toto

CPU: ldapUserAdd: ldap_add_s: Internal (implementation
specific) error
The error number was 80, please add an appropriate
entry to ldap_errors.c.
If you are unable, please email
cpu-users@lists.sourceforge.net with the error number
and what operation was being performed at the time.

Compilation error ld.c line 806

2006-10-14T18:20:33Z

cpu compilation failed on
gid = ldap_get_values (ld, pos, gid)[0];
line 806
it works like this
gid = ldap_get_values (ld, pos, gid);

Broken link on project home page

2005-03-14T15:55:55Z

The link to the Changelog
(http://www.dbaseiv.net/code/changelog.cpu) on the home
page (http://cpu.sourceforge.net/) no longer works, and takes
you to an advertising site.

User added to initial group

2005-02-21T17:00:13Z

With cpu 1.4.3 and the following configuration:
USERGROUPS = no
USERS_GID = 1000
when doing:
cpu useradd testuser
testuser gets explicitly added to group 1000:
$ cpu cat passwd | grep testuser
testuser:x:100:1000::/home/testuser:/bin/bash
testgroup:x:1000:testuser

I've modified CPU's source to try to avoid this behaviour and it
seems to work for me:
$ diff orig/cpu-1.4.3/src/plugins/ldap/user.c
cpu-1.4.3/src/plugins/ldap/user.c
425c425
< if (ldapres > 0)
---
> /* if (ldapres > 0)
428c428
< }
---
> }*/

I haven't sent this in as a patch because I'm not confident
enough with CPU source, but to me the problem seems to be
that ldapUserCheck() also adds the user to the group when
globalLdap->gid is not NULL. AFAIK, this gid is the ascii name
of the user's initial group, to which he doesn't need to be
added.

Best regards,
Carlos

Unable to perform operations on users with $ char in the nam

2005-01-02T11:51:51Z

I tried using cpu to manage my LDAP with samba accounts
in it. I know samba can do LDAP itself, but for some
historical legacy reasons my current setup just doesn't
use LDAP itself. So I replaced in the machine add
script /usr/sbin/useradd with cpu useradd to let samba
add machine accounts to the LDAP server.

This, however, does not work as samba adds an $ to the
end of machine account user names. This way I cannot
remove such accounts using cpu as well. If I remove
the $ in a manual test all works well. As soon as
there is a $ in the login cpu acts as if it was not
given at all. I think this is incorrect, as the
original useradd unix tool is able to add such user.

example output:
# /usr/sbin/cpu useradd -d /dev/null -g machines -c
'Machine Account' -s /bin/false test_machine
User test_machine successfully added!
# /usr/sbin/cpu useradd -d /dev/null -g machines -c
'Machine Account' -s /bin/false test_machine$
usage: cpu user{add,del,mod} [options] login
usage: cpu group{add,del,mod} [options] group
usage: cpu cat

usage: cpu useradd [options] login
-c comment --gecos=COMMENT : Gecos
Information
-d home_dir --directory=home_dir : Users home
directory
-g initial_group --gid=initial : The group id
or name of the user's
initial
login group
-G group,[...] --sgroup=group,[] : A list of
supplementary groups
-k[skeleton_dir] --skel[=dir] : The skeleton
directory
-m --makehome : The user's
home directory will be
created if
it does not exist
-p[passwd] --password[=password] : The
unencrypted password
-s shell --shell=shell : The name of
the user's login shell
-u uid --uid=uid : The
numerical value of the user's
ID.
-X script --exec=script : Post add script

some (relevant?) version information:
# cpu --version
CPU 1.4.3
Written by Blake Matheny
Copyright 2001, 2002, 2003

2.6.9 linux kernel Gentoo

bad behaviour when doing cpu usermod

2004-10-23T12:19:34Z

i am using CPU 1.4.3 on debian sarge and i dont know
wether this is intentionally or a bug:
when i do a "cpu usermod" all of my secondary group
memberships are resetted.
when specifiing the -G option with an empty list this
would be normal behaviour in my oppinion. but even if i
dont specify this option (e.g. i just want want to
change users passwd, gecos or something else), the
secondary group memberships are resetted to be empty.
as a workaround i had to look up the group memberships
before i modify a user in any way (doing a "cpu cat").
then i could do a "cpu usermod" giving the -G option
with the desired memberships and any other modifiing
option.

i cant imagine that behaviour is wanted :)