(solved) cannot view or support epoptes clients

Hi Jori,

First, there are two epoptes-client instances that have to run in order for all features to work properly. One epoptes-client is executed as the current user who's logged in on the client, and the other is executed as the root.

It seems that your user epoptes-client can't connect to the epoptes daemon for some reason. Could you please open epoptes from a console, let the client(s) connect, and give us the output?

Fotis

Hi Fotis,

sure, but I'm afraid, that doesn't help much under my configuration.
If I start

<ltsp-remoteapps epoptes>

on my fat-client, that is supposed to run the gui. Gui starts, but then I get a new prompt again and no further information shows up.

on the client in Terminal I run and get:

--- begin
/usr/sbin/epoptes-client
 * Epoptes-client connecting to server:789... ...done.
--- end

and that's it. Maybe I misunderstood what You wanted me to do. If so pls. get more into details because ltsp and epoptes are a pretty new environment for me . . .

Jori, try `ltsp-remoteapps xterm` first, and then launch epoptes inside that xterm.
Then run /usr/sbin/epoptes-client from the client, and paste any errors that you see on your epoptes/xterm output.

Hi alkis,

sorry I didn't know, I was supposed to open epoptes plausibly in a terminal on the server. I'm not deep enough into details of Your project.

Here the nesessary information in form of terminal output:

---begin
piet@hera:~$ epoptes

(epoptes:24593): libnotify-WARNING **: Failed to connect to proxy
Got clients: 10.1.1.3:52168, 10.1.1.3:60272, 10.1.1.5:38740
New connection from 10.1.1.5:58297
Disconnect from 10.1.1.5:58297
Unhandled Error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/twisted/protocols/amp.py", line 889, in _commandReceived
    deferred = self.dispatchCommand(box)
  File "/usr/lib/python2.7/dist-packages/twisted/protocols/amp.py", line 946, in dispatchCommand
    return maybeDeferred(responder, box)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 133, in maybeDeferred
    result = f(*args, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/protocols/amp.py", line 1035, in doit
    return maybeDeferred(aCallable, **kw).addCallback(
--- <exception caught here> ---
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 133, in maybeDeferred
    result = f(*args, **kw)
  File "/usr/lib/python2.7/dist-packages/epoptes/daemon/uiconnection.py", line 51, in clientDisconnected
    self.client.amp_clientDisconnected(handle)
  File "/usr/lib/python2.7/dist-packages/epoptes/ui/gui.py", line 451, in amp_clientDisconnected
    if not client is None:
exceptions.UnboundLocalError: local variable 'client' referenced before assignment
  **Twisted error: when enumerating client 10.1.1.5:38740: [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionDone'>: Connection was closed cleanly.
]
  **Twisted error: when enumerating client 10.1.1.5:38740: [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionDone'>: Connection was closed cleanly.
]
  **Twisted error: when connecting client 10.1.1.5:58297: [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionDone'>: Connection was closed cleanly.
]
  **Twisted error: when enumerating client 10.1.1.5:38740: [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionDone'>: Connection was closed cleanly.
]
---end

well, this looks serious. Hope it helps to trace the error . . .

piet

Jori, let's talk a bit about the last paragraph of your initial question:

"Additionally anybody is welcome to give a hint where to start the ltsp-client best. Gnome's <startprograms> or the <rc.local>-file don't seem to be the right places for that as they don't work as expected. On top of that the <ltsp-client -c> order has to be run after every reboot to get the Server's key. I tried to do it once in chroot to accomplish the action but that doesn't work."

When you say `ltsp-client -c`, I suppose you mean `epoptes-client -c`, right?
You don't have to put that anywhere, it doesn't have to run on boot or on login.
You only have to run it once inside your chroot. As mentioned in the http://www.epoptes.org/installation page, do:
sudo chroot /opt/ltsp/i386
epoptes-client -c
exit
sudo ltsp-update-image

Also if you have put `epoptes-client -c` anywhere in your boot or login scripts, remove it, as it might break things instead of fixing them.

Finally, you said: " I tried to do it once in chroot to accomplish the action but that doesn't work."
What didn't work? If for some reason `epoptes-client -c` doesn't work from your chroot, then try: `epoptes-client -c localhost`.

Hi alkis,

1. yes, indeed I ment <epoptes-client -c>. That was a real lapsus, sorry.

2. misunderstanding . . . I didn't put <epoptes-client -c> into any kind of boot-environment. I said I had to repeat it after every boot to make the whole thing work, because I tried to do it in chroot once and that didn't work.

3. Your discription now did the job so I finally could pick the key and pack it into the image. Don't know what went wrong the first time. Most probabely I made a mistake. So thank You.

4. what I wanted to put into a boot environment and was looking for a place to do it was the <epoptes-client> order (without -c). This has to be started after every (client-) boot (if I want the client to be ready to interact with epoptes) as far as I understood Your instructions in the fat client wiki page, hasn't it?

Hi alkis,

with a couple of more tests after these changes, I found out that it is obviously not necessary to start <epoptes-client> after reboot any more. That has something to do with the upper actions in chroot probabely? So these are the circumstances You wanted it to be, I guess.

The fact that only fat-icon appears and no viewing and supporting is possible remains up to now.

piet

Jori,
epoptes-client is configured when it gets installed to start automatically on boot, so no, you won't need to do this manually.

Jori, the previous output you pasted from `ltsp-remoteapps xterm; epoptes`, had problems because of the certificate mismatch.
Can you do it again now that the certificate was transferred correctly?

Also, do you have epoptes (not the client) installed in your chroot?
sudo chroot /opt/ltsp/i386 dpkg-query -W epoptes
If yes, please uninstall it and run ltsp-update-image again.

Also note that it may be easier to find us in IRC for some real-time troubleshooting. You can find a link for the IRC channel in the Epoptes Help menu.

>Also, do you have epoptes (not the client) installed in your chroot?
>sudo chroot /opt/ltsp/i386 dpkg-query -W epoptes
>If yes, please uninstall it and run ltsp-update-image again.

--- begin
ltsp-chroot -pcd
apt-get purge epoptes
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
Paket epoptes ist nicht installiert, wird also auch nicht entfernt.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
--- end

if this is the correct way to uninstall -> I obviously didn't install it in chroot . . . but that wasn't - as far as I remember - not mentioned in Your instructions.

>Also note that it may be easier to find us in IRC for some real-time troubleshooting. You can find a link for the IRC channel >in the Epoptes Help menu.

We already used Your channel for short interventions, so basically yes, but for this problem a lot of stuff has to be written. So I would have to put it in pastebin or equivalent anyhow - not to stuff Your channel. On top of that plenty of tests have to be made in between and I don't want to get under pressure doing them being in a hurry. So I think for this prob it is the better way, unless You insist in doing so.

I'll do the next tests tomorrow, because I've to get back to the office to do them and its close to 11 pm. It's even Your time to stop as well, isn't it? :)

thank You for now as always

piet

Hi alkis,

well, well now shapes reveal out of diffuse pictures. I did the test again and now:

--- beginn
piet@hera:~$ epoptes

(epoptes:17513): libnotify-WARNING **: Failed to connect to proxy
Got clients: 10.1.1.3:37248, 10.1.1.3:53300, 10.1.1.5:39943, 10.1.1.5:55680
---
**addClient's been called for 10.1.1.5:55680
* Won't add this client to my lists
---
**addClient's been called for 10.1.1.3:53300
  Continuing inside addClient...
* This client is a new one, creating an instance
* I am a root client
New connection from 10.1.1.3:53536
---
**addClient's been called for 10.1.1.3:53536
  Continuing inside addClient...
* This is an existing client
* I am a user client, will add piet in my list

VNC Viewer Free Edition 4.1.1 for X - built Feb 6 2012 06:09:48
Copyright (C) 2002-2005 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.

Sun Feb 26 12:22:00 2012
 main: Listening on port 5500

Sun Feb 26 12:22:02 2012
 CConn: Accepted connection from 0.0.0.0::47239
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8
 TXImage: Using default colormap and visual, TrueColor, depth 24.
 CConn: Using pixel format depth 6 (8bpp) rgb222
 CConn: Using ZRLE encoding

Sun Feb 26 12:22:03 2012
 CConn: Throughput 20000 kbit/s - changing to hextile encoding
 CConn: Throughput 20000 kbit/s - changing to full colour
 CConn: Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn: Using hextile encoding
 CConn: Throughput 20000 kbit/s - changing to raw encoding
 CConn: Using raw encoding
--- end

from the moment on when I ran </usr/sbin/epoptes-client> the Icon changed to a refreshing screen picture and the whole thing started working like expected.

But now I get the stange feeling that I misunderstood the concept completely. Do I have to start the epoptes-client or don't I?

You just said:
>epoptes-client is configured when it gets installed to start automatically on boot, so no, you won't need to do this manually.

but if I don't do it, I have my buggy handling back. So I guess I have to do it and I'm back to my additionally question: Where is the best place to put it, to make it work automatically?

Sorry if this sounds stupid, but it really confuses me.

piet

and there 's a gtk warning-message back that I forgot to mention:

---begin
(screenshot:11245): Gtk-WARNING **: Im Modulpfad »pixmap« konnte keine Themen-Engine gefunden werden,
--- end

that repeats constantly. (It means something like: it couldn't be found a themes-engine in module-path >pixmap< .)

Is there something to do about it?

When a fat client boots, you see the blue fat icon. This connection is started from /opt/ltsp/i386/etc/network/if-up.d/epoptes-client.
When a user logs in, you should be seeing his screen as a thumbnail. This connection is started from /opt/ltsp/i386/etc/xdg/autostart/epoptes-client.desktop.

From gnome, if you run `gnome-session-properties`, you see the services that run for the users. I hope you didn't go there and disabled epoptes-client. Try with another user to make sure that's not the problem.

If you don't find out why autostart items don't run for you, I think some real-time troubleshooting will be necessary.

Hi alkis,

after You told me, not to boot <epoptes-client> via boot-media I deleted it :)
Now everything is working fine. I reenabled it.

Thank You for Your help and the additional information - that was what I was missing. Fotis mentioned the first steps in his answer. Unfortunately that was not enough to get the clue for me at that time.

piet

The problem was solved, marking the question as "answered".