"an error occurred while connecting: 2"

Try the easy way first:
1) Remove the local epoptes group
2) Add an ldap "epoptes" group. Not epoptesadmin, just epoptes.
3) Restore the epoptes configuration files as they were.
4) Reboot servers/clients so that you make sure that the services/sockets are launched with the correct groups (or restart the epoptes service, use newgrp to launch epoptes etc)

Does this work?

thank you for fast reply.

unfortunately, it doesn't work.
I've the same error. :-/

Try this:

strace -e trace=file epoptes

This will tell you which file it tries to access.
Then check the permissions/owner of that file with
ls -lha file

uhm.. I tried, but it gives hundreds of not existing files and I don't know which one is hanging the process (as the last row is a localization file correctly found).

many of them are correctly lacking (i.e. epoptes tries to access localization files in many paths, and obviously only one of them is correct). any suggestion?
thank you..

I tried to create a new local (edubuntu) user group called "testgroup" and enable it using /etc/default/epoptes
it works like a charm.
it's only with LDAP groups that it doesn't work. If it could be useful, I'm using likewise-open to connect edubuntu to AD (i correctly added an AD user group to sudoers).

> it works like a charm.

Yup, we've tested that, it's not a problem in Epoptes itself.

I haven't ever used LDAP. I wonder if LDAP users/groups have access to local sockets (and especially when system services are concerned, which don't use PAM).

I can only suggest that you try to find me in IRC, so that we share a terminal and I take a remote look (it's easy, screen + socat).
I saw your question earlier in #ltsp, but only after you left... come again. :)

Some commands to play with:
ls -ln /run/epoptes/epoptes.socket
grep SOCKET_GROUP /etc/default/epoptes
getent group <the SOCKET_GROUP>

All those should be the same in order for the epoptes service to have access to the socket...

ok, a step forward...
the lacking directory is /run/epoptes
unfortunately I don't know how sockets are managed in ubuntu..
I verified that /run/epoptes exists when the SOCKET_GROUP in /etc/default/epoptes is a ubuntu group and doesn't when it's LDAP's.

maybe the application service starts before LDAP is loaded by likewise.

if i run
getent group epoptesadmin
note down GID
sudo edit /etc/group
add a row with
epoptesadmin:x:GID [faking the ldap group]

restart ubuntu

sudo delgroup epoptesadmin

then epoptes run properly with LDAP users too.
I don't know how to automate that procedure... or if some changes in epoptes could solve it.

You can make a startup script that does that, sure, but it can't go upstream in epoptes as it would be an ugly workaround. A better solution is needed.

Try again what I proposed in comment #1, but after restarting the server, check the status of the epoptes service:
sudo service epoptes status

Then restart the service:
sudo service epoptes restart

And finally, check syslog for errors:
tail /var/log/syslog

If it works by restarting epoptes, then it's a service startup sequence issue. If not, we need to see why epoptes can't read/use the LDAP gid.

I checked: status says that there's no PID for epoptes service.
restarting it, it works. I could think about resatrting it before trying to do the rough test of yesterday.. but I was pretty tyred ;-)

in syslog, there's nothing about epoptes.

I tryed to add likewise and lwsmd to #should-start and #Should-stop section of /etc/init.d/epoptes.config
i needed to add a simlink to insserv
sudo ln -s /usr/lib/insserv/insserv /sbin/insserv

then
sudo insserv epoptes
it gives a bunch of errors (both likewise and lwsmd are converted to Upstart) and messed up everything.

..so I turned back to the previous snapshot of ubuntu virtual machine and manually renamed simlinks in /etc/rc?.d moving only the epoptes one...

it works, but as I have to reproduce this work in multiple site, an automatic (and safer) alternative could be useful... any suggestion?

Thanks Alkis Georgopoulos, that solved my question.

I tried the "opposite":
sudo update-rc.d -f epoptes remove
sudo update-rc.d epoptes default 22 7

and it works too. could I expect any trouble or I should move epoptes-client too?

clearly your solution is better if there's some other service that uses likewise.. but just for trying...

so thank you for your assistance!

> could I expect any trouble or I should move epoptes-client too?

I don't think you should expect any trouble.
The epoptes-client service isn't needed in recent versions as it's started from if-up, it's only there for old LTSP versions that don't get if-up.d events, so no need to move it.

thank you!
now I'm starting another question... ;-)
easier, I hope.