Re: [phpGroupWare-users] phpGW for Unix users managed by LDAP

[Chris Weiss]

On 10/25/06, Emanuel Ziegler <address@hidden> wrote:
> Hi,
>
> I'm running a Debian (sarge) web server with Apache2 for our institute. The 
> installation of phpGroupWare was simple, but the configuration does not seem to 
> fit perfectly. I got the following problems:

what php version?  not sure it matters here, but just for the record
in case it does.  I have personaly experienced a coulpe bugs with
debian's php version outside of phpgw.  there are known work arounds,
but the particualr version Sarge comes with has behaviours that don't
exist in older or newer php versions.

> 1) eMail: The eMail-server is a Courier IMAP server that stores its mails via 
> Postfix in ~/Maildir. Direct access to the maildir does not seem to be 
> supported, but the IMAP needs a password although it is the same as the user 
> password. This forces the users to enter it by themselves and it does not run 
> out of the box for them.

it should work "out of the box" if the passwords are the same and
after you configure the email app.  Admin->Email->Site config.  enter
the server name and choose Courier as the type, if your IMAP logins
reaquir the "address@hidden" format, also choose "vmailmgr" style.
as for direct reading, it's the same reason as for teh FIleManager
home dirs, apache does not have access to users home dirs.

> 2) Password changes: Users are forced to change their password after first 
> login. This is uncomfortable and should be deactivated (since  it is their 
> login password).

this didn't used to be case, I thin it's filed as a bug.

> 3) LDAP: I managed to allow logins by LDAP and store additional information in a
I agree with Dave on this one, it just needs a "common" account.  the
auth isn't done directly via ldap, but the common account logs in and
check the users hashes

> 4) UID, GID, Groups: Currently only authentication is done via LDAP. As soon as 
> a user logs in, an account on MySQL is created with a new numeric UID, 
> independent group managment and home directories. I want, however, 
> phpGroupAdmin to use the information stored in the posixAccount and posixGroup 
> classes of the LDAP. In principle this information is available via PAM as well.

the reason for this is that a long time ago someone decided it was
easeir to store groups and users in the same table using the the same
UID namespace, and thus users and groups in phpgw cannot have the same
UID's like they can in Posix accounts.  I complained then, but I was
reasonably new to the project so i was ignored.  at this point,
"fixing" it is a major task likely to break many things.

> 5) Filemanager: I'd like to allow the users access to their home directories 
> instead of creating new home directories without content. Apart form that the 
> home directory seems to be set to /home/$user which is very inconvenient, since 
> the home directories are automaounted to /home in the format 
> /home/$server/$number/$user.

simple permissions.  apache runs as the unix user apache or http or
wwwroot, and thus everything it does on the file system it does as
this user.  the main problem you will have with the users home dirs is
that they will not understand this permission issue, and when they
create a file via some unix auth system (ssh, ftp, sftp, imap) the
file will be unaccessable in FileManager.  Then, when they create a
file in FileManger, it will be owned by apache and the user will not
be able to access it via other means.    Even with Daves symlink
suggestion, you are going to find this very difficult to deal with.
Maybe a vfs backend could be made to work over ftp, but currently
there is no way to change the process ownership to the "auth'd" user.
There is an "ftp" app in phpgw, though it is not perfect and has been
unmaintained for many years.  it might still work well enough for
users to download files to their local pc and then upload the changes.

> Sorry for the amount of questions. Maybe there are simple answers to this - I 
> guess not so uncommon - problems.

questions sometimes bring out solutions that just haven't been thought
of yet so ask away :)
half the issues here though are technical limitations of running via
apache.  there may be work arounds, but the solutions either aren't
implemented or just aren't easy/obvious.

> Thanks,
>     Emanuel

(and I did read Dave's reply forst, I just felt like expanding on his
answers, hopefully between the 2 responces you can understand some of
the limitations and come up with a solution to meet your needs.)