Please do NOT cross-post to both mailing lists. I'm removing the dev@ list
from this e-mail and ONLY responding on the user@ list.

On Wed, Jul 23, 2025 at 11:15 AM Savinder Kaur <[email protected]> wrote:

> Hi Team,
>
> Could you please share your suggestions on the following:
>
> - Storing session recordings directly in object storage (e.g., S3/MinIO)
> instead of the default local file system, without modifying the guacd
> (server)
>
- The minimal, production-ready changes required in the Guacamole backend,
> such as the ideal hook point after the `.guac` file has been finalized
>
- Whether there is any existing extension point, service, or architectural
> pattern in Guacamole that supports this use case
>
- Any potential concerns or limitations with uploading the `.guac` file to
> object storage after `guacd` completes the recording
>

> The goal is to implement this in a maintainable, production-grade manner
> that aligns with Guacamole’s architecture — ideally via an extension or
> injectable service within the Java backend.
>

I can think three possible ways to do this:
* Mount a directory with s3fs on the system running guacd, and point the
recording path at the s3fs directory. s3fs allows you to make S3 services
appear as standard mountpoint in Linux, so you can write to them without
any modification to the existing code. My caution, here, is that, having
never tried this before, I don't know exactly how well it will work with
something like the Guacamole recordings where the data is being streamed
into the file a little at a time. I _think_ it would work fine, but you
should test it if you intend to use it.
* Use a tool like rclone or the AWS CLI to copy the files to the S3 storage
once they have been written and closed. You can use a tool like inotify on
Linux to "watch" the recording directory and wait for a "CLOSE" of the
file, then do something with the file (aws s3 cp or rclone cp, etc.).
* If you run Guacamole Client and guacd on the same system, you could write
an extension for Guacamole Client that performs the upload to S3 after the
connection is closed. This would allow you to write Java code and leverage
the extension framework; however, you'd want to do some testing and make
sure that the .guac files are actually closed/flushed to disk when the
client reports the connection as closed - I do not believe there is any
mechanism in guacd, today, that guarantees that the recording is completely
flushed to disk at the time that the client sees the connection as closed.

Outside of that, as guacd is the component that actually writes the
recording files, if you wanted to make guacd do the upload natively, you'd
need to make some modifications to the guacd source code - it currently
does not have a way to natively write to anything except the local
filesystem.

-Nick

>

Reply via email to