Hi, I've implemented x2go with likewise-open, still I do have 2 issues, which are present only when I use LDAP account, and not present with regular account on the linux. More details: OS Ubuntu 10.10; x2go 3.0.1-5; likewise-open 5.4.0.42111. Ubuntu is joined to Windows Active Directory through LDAP. I don't have any issues there, and everything work fine with this configuration (one issue that I've overcome: when joining LDAP, the users have other group IDs, which came from LDAP. In order to connect to x2go server, your username must have the x2gousers group assignment. In my case in LDAP I do have special group which contains users who have to have access. I've logged to LDAP locally on the ubuntu, and using command id I've checked the unique identification of that LDAP group. Then I've set this number to the x2gousers in the file /etx/groups. This way I overwrite the group that came from LDAP with the local group, and only these users can connect to x2go).
Note: I've read all the documentation and I still didn't find solutions for my issues. They are:
- Connecting remotely with x2go client with LDAP credentials doesn't forward sound - thus no sound can be heard. This problem doesn't occur when I login locally on the Ubuntu with same LDAP credentials. When I'm logged in locally, the next remote login (using the client), has sound. However, I thought that it is something with groups for audio, but seems it is not, as I'm using very same credentials and the only difference is local and remote, this way all user permissions are same (confirmed)...
- Connecting remotely with x2go client with LDAP credentials doesn't stop the session, when disconnected in every way. The session remain open (visible with x2golistsessions_sql HOSTNAME). I've made around 20 client sessions from one host, and on the next ones it refused to connect me, because the number of authentications were too much. Again, when doing this locally on the Ubuntu, the sessions really terminate. I've even replaced x2gosuspend with x2goterminate, without any success. The only way is to delete file /var/db/x2go/x2go_sessions and to create empty one with /usr/lib/x2go/script/x2gosqlite.sh. The live sessions still remain active, but this doesn't seem good solution. It is not possible to terminate or to resume open sessions with the client as well. So they stay like zombies there.
Do you have an idea what can be the root causes for these issues? My logic lead me to some un-escaped symbols used when joining the Domain - like @ and \. Because when logging to the LDAP I am using USERNAME@DOMAIN. Another possibility is to be from Likewise-open, still, there should not happen this as locally everything works fine.
Best Regards Ivan
<snip> have special group which contains users who have to have access. I've logged to LDAP locally on the ubuntu, and using command id I've checked the unique identification of that LDAP group. Then I've set this number to the x2gousers in the file /etx/groups. This <snip>
- Connecting remotely with x2go client with LDAP credentials doesn't forward sound - thus no sound can be heard. This problem doesn't occur when I login locally on the Ubuntu with same LDAP credentials. When I'm logged in locally, the next remote login (using the client), has sound. However, I thought that it is something with groups for audio, but seems it is not, as I'm using very same credentials and the only difference is local and remote, this way all user permissions are same (confirmed)... <snip>
Update: /etx/groups was not the right path. The right path was: /etc/groups
Issue 1: When logged locally with LDAP credentials, and then remotely with same LDAP credentials. The sound which is heard is actually heard from the Server, but not from the Client :(. I've just found out this, as the computers are physically next to each other. And the sound is heard on the client side, when logged with local (non LDAP) user.
Best Regards Ivan
On Tue, 2010-12-14 at 08:32 +0200, Ivan Boyadzhiev wrote:
Hi, I've implemented x2go with likewise-open, still I do have 2 issues, which are present only when I use LDAP account, and not present with regular account on the linux. More details: OS Ubuntu 10.10; x2go 3.0.1-5; likewise-open 5.4.0.42111. Ubuntu is joined to Windows Active Directory through LDAP. I don't have any issues there, and everything work fine with this configuration (one issue that I've overcome: when joining LDAP, the users have other group IDs, which came from LDAP. In order to connect to x2go server, your username must have the x2gousers group assignment. In my case in LDAP I do have special group which contains users who have to have access. I've logged to LDAP locally on the ubuntu, and using command id I've checked the unique identification of that LDAP group. Then I've set this number to the x2gousers in the file /etx/groups. This way I overwrite the group that came from LDAP with the local group, and only these users can connect to x2go).
Note: I've read all the documentation and I still didn't find solutions for my issues. They are:
- Connecting remotely with x2go client with LDAP credentials doesn't forward sound - thus no sound can be heard. This problem doesn't occur when I login locally on the Ubuntu with same LDAP credentials. When I'm logged in locally, the next remote login (using the client), has sound. However, I thought that it is something with groups for audio, but seems it is not, as I'm using very same credentials and the only difference is local and remote, this way all user permissions are same (confirmed)...
- Connecting remotely with x2go client with LDAP credentials doesn't stop the session, when disconnected in every way. The session remain open (visible with x2golistsessions_sql HOSTNAME). I've made around 20 client sessions from one host, and on the next ones it refused to connect me, because the number of authentications were too much. Again, when doing this locally on the Ubuntu, the sessions really terminate. I've even replaced x2gosuspend with x2goterminate, without any success. The only way is to delete file /var/db/x2go/x2go_sessions and to create empty one with /usr/lib/x2go/script/x2gosqlite.sh. The live sessions still remain active, but this doesn't seem good solution. It is not possible to terminate or to resume open sessions with the client as well. So they stay like zombies there.
Do you have an idea what can be the root causes for these issues? My logic lead me to some un-escaped symbols used when joining the Domain
- like @ and \. Because when logging to the LDAP I am using USERNAME@DOMAIN. Another possibility is to be from Likewise-open, still, there should not happen this as locally everything works fine.
Best Regards Ivan Hmm . . . I do not know the answer. We are using LDAP authentication and it is working well (RedHat Directory Server). We are using local groups but the members are defined in LDAP. However, we are using uid to identify the user rather than email so your hunch about the unescaped characters might be correct.
The connections are really provided by ssh. What happens if you try to establish a simple ssh connection using the username@domain rather than x2go? - John
Hmm . . . I do not know the answer. We are using LDAP authentication
and it is working well (RedHat Directory Server). We are using local groups but the members are defined in LDAP. However, we are using uid to identify the user rather than email so your hunch about the unescaped characters might be correct.
The connections are really provided by ssh. What happens if you try to establish a simple ssh connection using the username@domain rather than x2go? - John
Thanks for your reply John,
We are using Windows LDAP, which is in productive for Windows Terminal Server. Now I'm testing migration to x2go. Thus, we can't replace the current LDAP server. And all groups are defined in LDAP. They are visible when logged in with LDAP credentials, and the group ids are 10 digit numbers. However. I have little update on my investigations.
Issue 1: Summary from my update: the server)
- remote login LDAP account - no sound.
- when login locally with same LDAP account, the sound is there - both in remote and local places.
- still the sound comes out from the Server computer only, wherever it has been started from (started music on remote x2go, gives the sound getting out
Update: Now I have added the following rows in: /etc/udev/rules.d/70-persistent-net.rules SUBSYSTEM=="sound", GROUP="pulse" #tested with audio as well SUBSYSTEM=="sound", MODE="0666"
the result is: there is sound when logged only once with remote LDAP connection (no need of local login any more!), still the sound gets out from the Server PC only.
Then I continued investigations: logged remotely both to Local Account (the desired behaviour) and LDAP Account (both with sound):
alsamixer gives absolutely same result - audio is pulseaudio
gnome-volume-control gives different result
- for Local Account: Nothing in Hardware; Output is Windows waveOut PCM (or client speaker)
- for LDAP Account: Server sound card in Hardware; Output is Internal Audio Analog (again on the server)
** Update: LDAP Account with no sound: Nothing in Hardware; Output is Dummy Output; alsamixer returns same pulseaudio sound device
Bottom line so far: remote login with Local Ubuntu User - sound is forwarded to client; remote login with LDAP User - sound is not forwarded, but played on the Server
Issue 2: You are completely right. It is ssh related. I've read about the issue, and tried the suggested MaxAuthTries equal to 24, but then other error has been returned. I'm currently reading for better solution, along with checking the log /var/log/auth.log for more detailed information. Still I use windows client, and I can't use ssh-add -D for deleting the cache. I'm searching for equivalent there.
Bottom line: my solution with deleting sql session file has nothing to do with this. It is ssh number of tries.
Thanks for you reply, I am continuing working over the issues. Please, share if you have some thoughts about this update.
Best Regards Ivan
Hi,
On Tue, Dec 14, 2010 at 11:20:13AM +0200, Ivan Boyadzhiev wrote:
Hmm . . . I do not know the answer. We are using LDAP authentication [...]
Issue 1: Summary from my update:
- remote login LDAP account - no sound.
- when login locally with same LDAP account, the sound is there - both in remote and local places.
Local logins usually set permissions to access local devices (e.g. soundcard), this could cause the difference between remote and local logins.
[...] Bottom line so far: remote login with Local Ubuntu User - sound is forwarded to client; remote login with LDAP User - sound is not forwarded, but played on the Server
Could you check the groups the users are members of? Log in as the users and type "id" into a terminal. Are there differences?
Best regards, Erik
Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/ auerswald@fg-networking.de Tel: +49-631-4149988-0 Fax: +49-631-4149988-9
Gesellschaft für Fundamental Generic Networking mbH Geschäftsführung: Volker Bauer, Jörg Mayer Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630
Hi Erik,
Local logins usually set permissions to access local devices (e.g.
soundcard), this could cause the difference between remote and local logins.
That is correct and was my first assumption before my mistake with the sound getting out from server, while I thought it is from the client. I've checked the permissions at the very beginning. Still I didn't find /dev/dsp or /dev/mixer.
Could you check the groups the users are members of? Log in as the users and type "id" into a terminal. Are there differences?
Same here, I've checked the groups at first. The group difference between the local user and the LDAP one. The point was that local user has many local group assignment, while LDAP user - none. Then I've overwritten the x2gousers instead of other LDAP groups. It worked. Then tried same with groups as audio, pulse, pulse-access. Nothing changed. Then removed my local user from all groups (left him only in x2gousers) and the local user still has sound. It has sound even when remotely accessed with x2goclient.
Here is the current output from id:
- Local user output (visible through remote login): uid=1002(iboyadzi) gid=1002(iboyadzi) groups=1002(iboyadzi),1518862849(x2gousers)
- LDAP user output: (visible through remote login): uid=1518868450(DOMAIN\iboyadzi) gid=1518862849(x2gousers) groups=1518862849(x2gousers),1545(BUILTIN\Users),1518863944(DOMAIN\....) and tons of other group assignment came from LDAP.
Still something else small thing is, which I can't figure out.
Best Regards Ivan
Best regards, Erik
On Tue, 2010-12-14 at 11:57 +0200, Ivan Boyadzhiev wrote:
Hi Erik,
Local logins usually set permissions to access local devices (e.g. soundcard), this could cause the difference between remote and local logins.That is correct and was my first assumption before my mistake with the sound getting out from server, while I thought it is from the client. I've checked the permissions at the very beginning. Still I didn't find /dev/dsp or /dev/mixer.
Could you check the groups the users are members of? Log in as the users and type "id" into a terminal. Are there differences?Same here, I've checked the groups at first. The group difference between the local user and the LDAP one. The point was that local user has many local group assignment, while LDAP user - none. Then I've overwritten the x2gousers instead of other LDAP groups. It worked. Then tried same with groups as audio, pulse, pulse-access. Nothing changed. Then removed my local user from all groups (left him only in x2gousers) and the local user still has sound. It has sound even when remotely accessed with x2goclient.
Here is the current output from id:
- Local user output (visible through remote login): uid=1002(iboyadzi) gid=1002(iboyadzi) groups=1002(iboyadzi),1518862849(x2gousers)
- LDAP user output: (visible through remote login): uid=1518868450(DOMAIN\iboyadzi) gid=1518862849(x2gousers) groups=1518862849(x2gousers),1545(BUILTIN\Users),1518863944(DOMAIN \....) and tons of other group assignment came from LDAP.
Still something else small thing is, which I can't figure out.
<snip> I admit to not reading this carefully as I am running out the door but doesn't one also need to be a member of fuse (file sharing) and pulse, pulse-access, and pulse-rt? - John
<snip> I admit to not reading this carefully as I am running out the door but doesn't one also need to be a member of fuse (file sharing) and pulse, pulse-access, and pulse-rt? - John
Ok, after my final investigations, it seems problem with the escape of "@" which is changed to DOMAIN"\"User. Everything else is the same. Only, only pulseaudio ssh forward doesn't happen. I have found this inside /var/log/syslog:
Dec 14 16:01:43 bgtrmx02 pulseaudio[11757]: pid.c: Failed to open PID file '/home/likewise-open/DOMAIN/iboyadzi/.pulse/512381a4f3b57a9260ac14f100000005-runtime/pid': No such file or directory Dec 14 16:01:43 bgtrmx02 pulseaudio[11757]: pid.c: Failed to open PID file '/home/likewise-open/DOMAIN/iboyadzi/.pulse/512381a4f3b57a9260ac14f100000005-runtime/pid': No such file or directory
- I've compared 2 newly created user folders (local and LDAP). There had differences:
- media symlink to /tmp/DOMAIN\USER_media wasn't successful for LDAP user
- LDAP user has .pulse folder with the pid error above
- local user has .pulse-client.conf and .pulse-cookie inside ~/.x2go/C-Username...dp32/
- ps axwww compare showed no difference
The point with LDAP user logged in locally, has same effect as changing /dev/snd/* files permissions to 0666 (SUBSYSTEM=="sound", MODE="0666" part), and thus the sound is hearing on the server side.
My questions: like to try to create manually a new pulseaudio forwarding to current remote
- Do you know how this SSH Pulseaudio forwarding is implemented. I would
LDAP account session. 2. Can you show me where in the sources, are the parts written both for the server and client side. When I get more deep understanding how this pulseaudio is happening I would provide exact reason why it fails.
Thanks and Best Regards Ivan
On Tue, 2010-12-14 at 16:58 +0200, Ivan Boyadzhiev wrote:
<snip> I admit to not reading this carefully as I am running out the door but doesn't one also need to be a member of fuse (file sharing) and pulse, pulse-access, and pulse-rt? - JohnOk, after my final investigations, it seems problem with the escape of "@" which is changed to DOMAIN"\"User. Everything else is the same. Only, only pulseaudio ssh forward doesn't happen. I have found this inside /var/log/syslog:
Dec 14 16:01:43 bgtrmx02 pulseaudio[11757]: pid.c: Failed to open PID file '/home/likewise-open/DOMAIN/iboyadzi/.pulse/512381a4f3b57a9260ac14f100000005-runtime/pid': No such file or directory Dec 14 16:01:43 bgtrmx02 pulseaudio[11757]: pid.c: Failed to open PID file '/home/likewise-open/DOMAIN/iboyadzi/.pulse/512381a4f3b57a9260ac14f100000005-runtime/pid': No such file or directory
- I've compared 2 newly created user folders (local and LDAP). There had differences:
- media symlink to /tmp/DOMAIN\USER_media wasn't successful for LDAP user
- LDAP user has .pulse folder with the pid error above
- local user has .pulse-client.conf and .pulse-cookie inside ~/.x2go/C-Username...dp32/
- ps axwww compare showed no difference
The point with LDAP user logged in locally, has same effect as changing /dev/snd/* files permissions to 0666 (SUBSYSTEM=="sound", MODE="0666" part), and thus the sound is hearing on the server side.
My questions: this pulseaudio is happening I would provide exact reason why it
- Do you know how this SSH Pulseaudio forwarding is implemented. I would like to try to create manually a new pulseaudio forwarding to current remote LDAP account session.
- Can you show me where in the sources, are the parts written both for the server and client side. When I get more deep understanding how
fails.
Thanks and Best Regards Ivan
<snip> Hi, Ivan. Alas, I'm still flying in and out but you can find most of the scripts on the server under /usr/bin/x2go*. These scripts are invoked by the client via ssh.
We'll see if the list allows it through but I've attached an OpenOffice document of our analysis of what happens when an X2Go session starts and stops. It is a very rough document - really a scratch sheet of notes - but at least it is something to help you along. It may not be 100% accurate. Good luck - John
-
Erik Auerswald -
Ivan Boyadzhiev -
John A. Sullivan III