Hello

[Pengwin61]

Good afternoon. I am a Linux engineer my name is Kirill. I was inspired by your product and the fact that it can deploy terminal environment and vdi on unix like system. Close examination of the product made me realize that openUDS does not work with the most popular PostgreSQL database and that there is no detailed manual on how to run the product, as well as in requirements.txt is not limited to versions of dependencies.
Important! All manipulations were performed on version 3.5.0
What I did:
Project:

1. Rewrote the connector from mysql to postgres
2. Fixed django settings.py file, added dotenv library
3. fixed constant in /usr/share/openuds/uds/core/init.ru changed from VERSION = '3.x.x-DEVEL to VERSION = '3.5.0'.
4. Built all required packages .deb .rpm .deb .rpm

Infrastructure:

1. Wrote playbooks for deploying openuds server + actor + nginx

Production stand

1. FreeIPA - LDAP
2. openUDS server 2 ( active/passive )
3. OpenUDS Actors 6 ( Pool ) 4. X2go as transport because it works over ssh
4. NFS Server
5. Postgres as sql

The problems encountered were:

1. When a user connects to the broker, it takes actors from the pool by priority and makes a record in the database. If at that moment the actor fails, the user is disconnected and when reconnecting the broker looks in the database about previously created connections and tries to connect to the server that is not in the network.
2. If there are > 2 actors in the pool, they will have different home folders, which is not very good when the situation I described above happens. I have deployed NFS server and located there user directories. And used the standard FreeIPA automount tools. And it worked. But still the user home folders had to be created manually on the NFS server, as well as assign an owner to the folder, because the built-in mechanism in linux skelet did not work and did not create folders.
3. I could not manage sessions in any way, users can throw their sessions and not close them, and this can affect the performance of actors. And also it can be done manually, but I didn't like it.

So I wrote a small golang program called watcher that allows me to cover some of my needs:

1. It goes to FreeIpa and collects the list of users in the group, as well as their gui/uid and creates home folders for them on the nfs server
2. If a user's home folder has not been modified for a long time, watcher removes it from the NFS server.
3. In the configuration file is set a parameter on the duration of the session, if the user left the session, then within 4 hours watcher closes it.
4. If the user decided to connect directly through x2go directly to the actor, watcher monitors such connections and terminates the session.
5. watcher can assign user quotas according to those set in the configuration file. It can work with both xfs and ext4 quotas. Automatically understands it and assigns according to the deployed file system.
6. All user sessions are outlined in the web interface, as well as a hung session can be terminated from the web.
7. Authentication on the web is done via LDAP + JWT token

Roadmap:

1. Archiving user home directories before deletion, and possibly uploading them to s3
2. Prepare Dockerfile

[dkmstr]

Seems like a lot of work... :)

The fact it's not working with postgresql is lack of time for testings in fact, but as long as Django supports it, there should be not a big problem with that..
What changes did you made?

Also, what do you mean with "actor".. For me, the actor is the "agent" that runs on the vms...

I am currently making "heavy changes" in 4.0 (refactoring, migrating code to snake_case instead of camelCase (easier to read now for me, not so easy a few years ago :) ), and i have the intention to work on a "linux application server actor", in fact, i have started it already, but a long way to go (because i'm also rebuilding from scratcg standard actor for 4.0 release i hope)

Thank you very much for let me know about your work. If i can help in anything, please, let me know (notice that i have included, on 4.0, support for FreeIPA, thanks to Alexander that made it ;-)

Maybe some changes can be commited (if not most) to the mainstream of the 4.0, and ofc, the documentation of how to install and manage it... it's something that is needed a long time ago, but again, lack of time to do it.

Again, thank you very much!!

Anything i can do, please, let me know...

[Pengwin61]

Hi, by actor I mean uds-actor, the terminal server carrying the payload.
Yes, I know that Django natively works with postgres for this reason I thought it should not be a problem to add psycopg2==2.9.1 and python-dotenv to the requirements.txt file (the screenshot shows a library to read the parameters from the .env file so you can change them during testing). I am not a python developer, just devops, but can write in golang. I rewrote the connector to postgres for tunnel (see screenshot) .

I don't think there is anything hard for a developer there. Exploitation of openuds on postgresql subcode has been more than 6 months in production environment. The only problem occurred with x2go and mate shell conflict. Sessions were showing a black screen. For this reason I got tired of manually terminating the session and wrote a watcher that detects the number of usd-actors and terminates them. I chose x2go because it runs on top of ssh and it doesn't need to allocate a separate port and disturb my security department. My watcher is designed in such a way that it covers some of my needs that I encountered when architecting and running the product. Because the goal was to make a fault tolerant solution.

Unfortunately I did not build version 4.0, I needed to build a production environment from a more stable version for my users to replace the windows stack.
I have connected openuds server to freeipa via "Regex LDAP Authenticatior" it works 100%. I understand that you don't have time for everything, doing such a big project in one person is very hard and time consuming and there are other things to do. I am grateful for this product and if you need my help I would be happy to help. I think a good solution for you would be to write a Dockerfile that would allow you to quickly deploy openuds for testing and development. Maybe my wish would be to move the client component to golang to have less dependencies on the client side.

[dkmstr]

If your postgresql works fine, and you have been using it in production for such a long time without incidents (did the reports work fine for you?, this is where the "most strange" part of sql queries are. In 4.0, there are a lot of fixes with this also, but currently 4.0 is far from production ready, i have a lot of work to do... :) ), we can include the support for it directly. That is, include the requirements, and in the sample, include a default config so anyone can benefit from it.

With relation to shell, stuck sessions, etc.. What Provider are you using?, it's always possible to generate a customized one (or improve existing one) that allows some tasks (for example, before removal...)

The client part in golang, is something that i have been thinking about for a while. It's mainly in python for coherence (For example, i have a version of the tunnel in go lang, and another one in c++, but the "global" performance is very similar (in fact, golang processes the "open connection" stage infinitely faster than the others, but one it's stablished, there is low difference.

The idea also of python is to be able to update the "transports scripts" from UDS, and i also have been thinking to port them to something like lua (as long as they are signed, there is no problem with the language used). I'm including some changes for next 4.0 release, and will see in a future, but as long as we can execute these "transport scripts" on clients, a golang version should be a good one.
Relative to dependencies, we can always build the "portable" versions, but golang will remove a lot of issues on any plaform, i'm sure of it ;-)

I hope that after this summer (2024), 4.0 will be available as the current stable. I have refactored lots of code (most of methods, i hope all), included new mechanics (servers, that allows a more fine control of some environments), i wont to make a generic "LinuxAppServer" to be available, but currently only testing things around, allowing us to give "1 server for many users" consistently, and probably include some of the characteristics that you comments on your watcher...)

Again, thanks a lot for sharing your experience ;-)

[Pengwin61]

I didn't use the reports. My task was to provide employees with a non-windows terminal server so that they could work with corporate documents on the company's hardware. As for the provider, I only used Static IP Machines Provider. But I don't think that's the problem with it, since most of the problems are related to x2go and X11. Hotkeys and image sticking. I believe in you that version 4.0 will be excellent.

I have not tested the performance of the tunnel in different programming languages, but I suggested the client component for one simple reason, it is difficult for users to install a python interpreter on their personal computer, and golang is compiled into a binary file or in .exe depending on the platform, which is easier to distribute. It seems that there are libraries for python that allow you to perform such actions with it.

As for the general architecture, there is no need to focus only on python, since it is possible to build component communication through the REST API or gRPC. I am currently studying this technology and would like to apply it to watcher. This would allow me to terminate sessions directly on uds-actor, rather than via ssh connect

I'm sorry, I don't know English perfectly and I communicate with you through a translator and some points are not completely clear to me, what do you mean about LinuxAppServer?

[dkmstr]

Don't worry, the translations is very good :).
The Linux App Server is basically an specialized actor (or agent), for allowing the same that an MS RDS server, that is: terminal sessions on Linux servers...
All of this with native load balancing (based on real load), session control, messaging, etc...
Will allow to, for example, when done, to create an specialized version to use docker to isolate user sessions, tunneling external connections to the correct container (this is the last part i'll implemenet, to be honest :) ), or simply execute the application locally.

I think it's very similar to your current use, but with an specialized agent (so we can control logins, session use, etc...)

Hope i'm clear enough :)

[Pengwin61]

Yes, thank you, you explained it very clearly. I just had thoughts of encapsulating Static IP Machines Provider in an LXC container, it looks more like a full-fledged linux than docker containers. I want to thank you again for your product, it is far from ideal, but it is going in the right direction. If you need my help, I will be happy to contribute to openuds. I have opened my watcher repository for you so that you can understand how it works. =)

[dkmstr]

Again, thanks for your offering ;-)

I'll take a close look to your watcher, sure i can take something for the LinuxAppServer that i want to bring.