Hi,
There is a way, besides of Veyon which could meet easily your need, and give you ideas : BGinfo.
https://docs.microsoft.com/en-us/sysinternals/downloads/bginfo

This is a small exe launched automaticaly at each start up of a computer and stopped immédiately after :
function : create a desktop wallpaper with the information you may need, color wished etc...
Then you can have: user name, host, group, IP, MAC...
you can chose position and size of all this.
for me top right, about 1cm height characters (i can see them in real from my desk and from veyon also)

Good luck

Have you verified that the key pair IDs are identical on all computers? Did you set the access group for public and private key files properly? The public key file needs to be readable by everyone/guest on all computers while the private key file should be accessible by Veyon Master users on the teacher computers.

@drewloker Have you tried disabling the mentioned option ("Enforce selected mode for client computers")? Currently this option causes problems with the demo mode in 4.5.x which will be fixed in the next release. However when disabling it, demo should work normally.

So I was able to fix the issue of the master not being able to see more than one computer. I deleted all the veyon files and reinstalled on all three PCs (master and two clients) and created a new key pair for the master and changed the access group to Users from the default Administrator then I exported that public key to the two clients after adding the clients to the master's Locations @ Computers list.

The weird thing is when I click the test button on the client PCs it still says Authentication keys not setup but the services work so that's all that matters.

@fred

Ahhhhhh, very smart and so easy. Thank you!

Does the chromebooks have Linux (beta)? Or blocked by admins?

@itguy Thank you. will follow steps given and update

@drewloker said in 4.4.2 - Downgrade options? CRASHES Master and Clients, No Demo:

Demo still doesn't work.
I brought the whole lab up to 4.5.4.0
It went to Demo, showed my screen for a few second on a couple of the 7 students logged in a lab of 26 clients. Then, Demo stopped working even on the couple that did get my screen.
I was able to back out of Demo mode with out crashing their computer.

Hello
i have the same problem .. i opened a new topic: https://veyon.nodebb.com/topic/1258/veyon-4-5-4-vnc-serveur-crash-on-demo-mode
where I put the logs to see if tobydox manages to understand what is wrong ...
Fred

Yes it is laggy. I love to let my students play. They usually complain about lag. I have decided to test this. I told on of the students to keep there game open and leave. I opened the app it was laggy and the lag stopped when I closed it.

I do have quite the same experience with a number of 25 computers in wifi.
You can probably increase the response by having the master on RJ45 network cable if possible.

@tobydox said in Can't telnet localhost 11100:

For further troubleshooting, first please update to the latest version available in our PPA (4.5.3-2) which contains additional fixes regarding session management. If it does not help, set the log level in Veyon Configurator to Debug, reboot, login and paste the output of /tmp/VeyonServ*.log here so we can examine it in detail.

I'm jumping in this thread as I have exactly the same issue.

$ telnet localhost 11100 Trying ::1... Trying 127.0.0.1... telnet: Unable to connect to remote host: Connection refused

Here are the debug logs:

$ sudo tail /tmp/VeyonServ*.log ==> /tmp/VeyonServer.log <== 2021-03-15T21:49:52.409: [DEBUG] PluginManager::loadPlugins(): discovered plugin "SystemUserGroups" at "/usr/lib/x86_64-linux-gnu/veyon/systemusergroups.so" 2021-03-15T21:49:52.410: [DEBUG] PluginManager::loadPlugins(): discovered plugin "TextMessage" at "/usr/lib/x86_64-linux-gnu/veyon/textmessage.so" 2021-03-15T21:49:52.411: [DEBUG] PluginManager::loadPlugins(): discovered plugin "UserSessionControl" at "/usr/lib/x86_64-linux-gnu/veyon/usersessioncontrol.so" 2021-03-15T21:49:52.412: [DEBUG] PluginManager::loadPlugins(): discovered plugin "WebAPI" at "/usr/lib/x86_64-linux-gnu/veyon/webapi.so" 2021-03-15T21:49:52.412: [DEBUG] VeyonCore::initSystemInfo(): "4.5.4" "potter" "linux" "5.4.0-67-generic" "Ubuntu 20.04.2 LTS" "ubuntu" "20.04" 2021-03-15T21:49:52.413: [DEBUG] FeatureWorkerManager::startUnmanagedSessionWorker(): Starting worker (unmanaged session process) for feature QUuid("{8e997d84-ebb9-430f-8f72-d45d9821963d}") 2021-03-15T21:49:52.418: [DEBUG] VncProxyServer::start(): started on port 11100 2021-03-15T21:49:52.418: [DEBUG] VncServer::prepare(): 2021-03-15T21:49:52.420: [DEBUG] VncServer::run(): running 2021-03-15T21:49:52.423: [DEBUG] VeyonCore::exec(): Running ==> /tmp/VeyonService.log <== 2021-03-15T21:49:12.526: [DEBUG] PlatformSessionManager::PlatformSessionManager(): 2021-03-15T21:49:12.527: [DEBUG] LinuxServiceCore::connectToLoginManager(): connected to login manager 2021-03-15T21:49:12.530: [ERR] LinuxServiceCore::startServer(): Can't start Veyon Server in Wayland sessions as this is not yet supported. Please switch to X11-based sessions! 2021-03-15T21:49:49.276: [DEBUG] LinuxServiceCore::startServer(): Session "/org/freedesktop/login1/session/_32" still opening - retrying in 1000 msecs 2021-03-15T21:49:50.297: [DEBUG] LinuxServiceCore::startServer(): Session "/org/freedesktop/login1/session/_32" too young - retrying in 1000 msecs 2021-03-15T21:49:52.323: [DEBUG] --- 2021-03-15T21:49:52.324: [DEBUG] Last message repeated 1 times 2021-03-15T21:49:52.324: [DEBUG] --- 2021-03-15T21:49:52.324: [DEBUG] PlatformSessionManager::openSession(): Opening session 0 for platform session "/org/freedesktop/login1/session/_32" 2021-03-15T21:49:52.325: [INFO] LinuxServiceCore::startServer(): Starting server for new x11 session "/org/freedesktop/login1/session/_32" with ID 0 at seat "/org/freedesktop/login1/seat/seat0"

Regarding the "Wayland ERR", it's not true!

$ echo $XDG_SESSION_TYPE x11

Anyway, what could be the next step in resolving this issue? Thank you for any help you could bring in.

Yes, /NoStartMenuFolder is indeed the correct option. Thank you for pointing out the missing entry in the documentation which just has been added.

maybe in the new release (4.5.4) this bug has been solved

Figured it go to registry Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Add a DWORD 32 BIT VALUE name it DisableTaskMgr and the value is 1. Windows 10. Do the same here to Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. It works on all verison of Window 10. Even Home.

@alexia74 Can you mention any information about it such as issues. Screenshots and show us the settings. Maybe we can resolve the issue we need further information.