a weird behavior with client about openuds HOT 9 CLOSED

With that information only, i cannot tell you if it is a bug, or what... Which UDS Version are you using? Which client version?...

Please, can you describe the steps to reproduce the problem (type of provider, type of connection, platform for the client, etc...), and also, include the information of uds.log and service.log so we can review it? also, in your home folder (if in linux) or your temp folder if from windows...

I need a lot more information to know what is going on. 3.6 is currently being used by LOTS of users, and we have not recieved that problem.

Anyway, the problem is not that the browser show the client download option (that is normal, if the client does not starts on local machine), it why the client is not starting probably...

If you can describe carefully the problem, the context, and the steps, i can review it.

Regards, and thanks for your report

from openuds.

Hello, I update my issue.

Platform: OpenUDS 3.6
Client: MacOSX, Sonoma, Python: 3.10.13, connect to VD with Microsoft Remote Desktop
VD: Windows 10
Provider: Openstack

Step:
VD (virtual desktop)

1. Login to OpenUDS web, and click to VD to connect throught tunnel with RDP
2. Client is used to connect to VD and successful.
3. After login successfully to VD, do something (do not care about how long you work on this VD) then choose disconect to quit from VD
4. After window of VD disappear, connect againt to VD. (It's very short time from you disconnect to VD). This time, an message "Service ready - OpenUDS Client not launching. It seems that you don't have Client installed. Please, install it from here..."

udsclient.log

from openuds.

can you also provide the uds.log file for the hours of the failure?

Even better:
1.- Clean up the log on uds server and uds client
2.- Ensure client is not running on MAC
3.- Make the process that fails and post them

The Situation is, at least, weird. The message means that the client is not asking for the data to open the remote machine, and is what is strange.

As an extra test, after the failure, full close UDS client and try again (i mean, before every try to connect to the machine, close or kill uds client locally)

Let's see if we can locate where the problem is :)

Thanks

from openuds.

Hi, to more detail, I think I find the reason. When UDSClient connect to VD, a thread is create to wait the disconnected signal and reject another ticket. So, if I disconnect to VD, the UDSClient need some minutes to execute endScript. In this small time, I create a new ticket to connect VD again, the ticket is rejected (previous connection is being ended). Then the website show not found message.

from openuds.

It may be an explanation, but should not happen...
Can you please test with the client from this url?
https://demo.udsenterprise.com/uds/res/clients/UDSClient-3.6.0.pkg
This version is the "corporate built one", must run in any place (it's the same code as open source code, but with its own build mechanisms, etc... )

The thing is that UDSclient, on darwin, uses https://github.com/VirtualCable/openuds/blob/v3.6/client-py3/full/src/UDSClientLauncher.py as launcher, not directly de UDSClient.py file, because if don't, the processor can only process ONE connection at the time, and may happen what you have said...
The provided client uses that as "main client", with an event listener for FileOpen (because if don't, "argument parser emualtion" wil "lock" the aplication and only 1 connection can be made, and can happen what you said).

How did you build the mac os client?, ensure that you don't allow "argv_emulation" and use "UDSClientLauncer.py" as main script on mac os

Hope this helps, and yes, the problem is probably what you have said, but due to "argv_emulation" and not using the "UDSCLientLauncher.py" as "main" script...

from openuds.

Hi, I tried with your packaged you provided. With this client, I can connect to multiple desktop in the sametime. I think it's different with my built client.
I build .app with this spec

# -*- mode: python ; coding: utf-8 -*-

block_cipher = None

a = Analysis(
    ['UDSClient.py'],
    pathex=[],
    binaries=[],
    datas=[],
    hiddenimports=[],
    hookspath=[],
    hooksconfig={},
    runtime_hooks=[],
    excludes=[],
    #win_no_prefer_redirects=False,
    #win_private_assemblies=False,         
    cipher=block_cipher,
    noarchive=False,
)

pyz = PYZ(
    a.pure,
    a.zipped_data,
    cipher=block_cipher
)

exe = EXE(
    pyz,
    a.scripts,
    [],
    exclude_binaries=True,
    name='UDSClient',
    debug=False,
    bootloader_ignore_signals=False,
    strip=False,
    upx=True,
    console=False,
    disable_windowed_traceback=False,
    argv_emulation=True,
    target_arch=None,
    codesign_identity=None,
    entitlements_file=None,
    icon=['macosx/uds.icns'],
)

coll = COLLECT(
    exe,
    a.binaries,
    a.zipfiles,
    a.datas,
    strip=False,
    upx=True,
    upx_exclude=[],
    name='UDSClient',
)

app = BUNDLE(
    coll,
    name='UDSClient.app',
    icon='macosx/uds.icns',
    bundle_identifier='UDSClient.app',
    info_plist={
        'CFBundleURLTypes': [{
            'CFBundleURLName': 'UDSClientUrlSchema',
            'CFBundleTypeRole': 'Viewer',
            'CFBundleURLSchemes': ['uds', 'udss'],
            'LSMinimumSystemVersion': '12.0.0'
        }]
    }
)

from openuds.

Try changing "UDSClient.py" by "UDSClientLauncher.py" as base application. I think that this should do the trick, because the fileopen that file is the one implementing the "FileOpen" event processor, and it's import UDSClient.py as "submudule", and uses it here:

Hope this helps ;-)

from openuds.

Did you resolve your issue?
I closed the issue because i guess it's solved, but in fact.. i don't know it :)
So please, let me know if it is solved or if i can help you with anything else.

from openuds.

I haven't re built it, I will test it this week, come back from holidays (lunar new year).

from openuds.