[LLT-5831] QNAP: move cgi logic to teliod #1012

lcruz99 · 2024-12-04T17:56:35Z

Problem

CGI consists in a bash script that handles http requests and directly control teliod daemon execution.
As in the near future more features (eg: authentication) are to be added, after internal discussions it was decided that would be more secure and easy to maintain/implement if the handling of the requests is moved to the teliod binary.

Solution

Make the CGI script redirect http requests to teliod.

☑️ Definition of Done checklist

Commit history is clean (requirements)
README.md is updated
Functionality is covered by unit or integration tests

tomaszklak · 2024-12-05T10:58:44Z

Can we use instead something like https://docs.rs/cgi2/latest/cgi/ or https://docs.rs/cgi/0.6.0/cgi/ , so that we avoid implementing irrelevant details of cgi/http, and focus on our business logic?

stalowyjez

imho looks strange, like someone wanted to write a shell script, but had to do it in rust for some reason

clis/teliod/src/qnap.rs

clis/teliod/src/main.rs

stalowyjez · 2024-12-05T15:19:32Z

clis/teliod/src/qnap.rs

+enum Action {
+    Start,
+    Stop,
+    UpdateConfig,
+    GetStatus,
+    GetTeliodLogs,
+    GetMeshnetLogs,
+    Invalid,
+}
+


What is the reason of creating this intermediate enum? It looks to me that you just make two match statements instead of one, without any visible gains.

It looks like that indeed, however I thought it would be good to have it like this so that we can expand it in the future.

in the end I'll change it with the http crate objects as you suggested below

clis/teliod/src/qnap.rs

stalowyjez · 2024-12-05T15:44:03Z

clis/teliod/src/qnap.rs

+    }
+
+    pub fn teliod_cfg() -> String {
+        format!("{}/teliod.cfg", Self::QPKG_DIR)


Teliod knowing where is the config file is a bit weird idea imho, in such case I would refactor it to exclude that argument and hardcode it in the rest of the code as well.

sorry I didn't understand, can you explain?

Currently teliod daemon starts with config file path provided as an argument - the situation where this path is at the same time hardcoded provided to and hardcoded in teliod doesn't feel right.

Other platforms certainly have a different path for the config file whereas for QNAP this is a static path, hence the idea of having it hardcoded.

clis/teliod/src/qnap.rs

lcruz99 · 2024-12-05T19:44:23Z

imho looks strange, like someone wanted to write a shell script, but had to do it in rust for some reason

@stalowyjez that was more or less what happened, but what do you think it looks strange besides other comments?

lcruz99 · 2024-12-05T19:46:46Z

Can we use instead something like https://docs.rs/cgi2/latest/cgi/ or https://docs.rs/cgi/0.6.0/cgi/ , so that we avoid implementing irrelevant details of cgi/http, and focus on our business logic?

@tomaszklak thanks for the recommendations, will take a look!

stalowyjez · 2024-12-06T09:43:14Z

@stalowyjez that was more or less what happened, but what do you think it looks strange besides other comments?

I mean it just doesn't look like a right tool for the job to me

clis/teliod/src/main.rs

clis/teliod/src/qnap.rs

clis/teliod/src/main.rs

clis/teliod/src/qnap.rs

qnap/shared/teliod.cgi

ghztomash · 2024-12-10T12:10:15Z

clis/teliod/src/qnap.rs

+    }
+
+    pub fn teliod_log() -> String {
+        "/var/log/teliod.log".to_owned()


Shouldn't these be retrieved from the config?

It's one possibility. Do you think other file paths should also be set on the config? or just teliod.log?

clis/teliod/QNAP.md

clis/teliod/src/qnap.rs

clis/teliod/Cargo.toml

clis/teliod/src/config.rs

tomaszklak · 2024-12-11T16:12:37Z

clis/teliod/src/qnap.rs

+        (&Method::POST, _) => start_daemon(),
+        (&Method::DELETE, _) => stop_daemon(),
+        (&Method::PATCH, _) => {


Please add verification of path.

verification of path?

For example in the documentation we say:

- **Endpoint**: `/` - **Method**: `POST`

But in code we start daemon after any post, regardless of the path. We should verify that the path is exacly /. Similar for DELETE and PATCH methods.

the Endpoint path / is relative to the teliod.cgi path. So / is equivalent to /cgi-bin/qpkg/teliod.cgi. I can check against this hardcoded path..

Is user able to control the path parameter?

If we expect that it will always be the same value (/cgi-bin/qpkg/teliod.cgi?) than there should be no reason not to check - if we are mistaken we want to know about this.

fair enough, added

Ugh.... I meant query not path 🤦

Hey let's not do path verification in this PR, let's leave it after we have a web page logic
also path() should only contain string afeter cgi-bin/qpkg/teliod.cgi,soforexample if cgi-bin/qpkg/teliod.cgi/xxx/x would be request, path should be /xxx/x.

In my setup i will rely that '/' path is return index page, and '/style.css' will return css and so on, so let's leave path out of this pr.

Query tipycaly should not be fragile, we disccuseed with luis already, but proper parsing should be done so for example:
?some-id=1&some-other=2 should be equivalent to ?some-other=2&some-id=1
We will add this with auth logic

will remove path verification. Query will indeed be validated on a next PR

clis/teliod/src/qnap.rs

tomaszklak · 2024-12-12T10:26:45Z

clis/teliod/src/qnap.rs

+        assert_eq!(
+            updated_config.log_level,
+            tracing::level_filters::LevelFilter::INFO
+        );
+        assert_eq!(updated_config.log_file_path, "/new/path/to/log");
+        assert_eq!(
+            updated_config.authentication_token,
+            "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
+        );
+        assert_eq!(
+            updated_config.app_user_uid,
+            Uuid::parse_str("11111111-1111-1111-1111-111111111111").unwrap()
+        );
+        assert_eq!(updated_config.interface.name, "eth1");
+        assert_eq!(
+            updated_config.interface.config_provider,
+            InterfaceConfigurationProvider::Ifconfig
+        );
+        assert_eq!(updated_config.http_certificate_file_path, None);
+        let mqtt_default_cfg = MqttConfig::default();
+        assert_eq!(
+            updated_config.mqtt.backoff_initial,
+            mqtt_default_cfg.backoff_initial
+        );
+        assert_eq!(
+            updated_config.mqtt.backoff_maximal,
+            mqtt_default_cfg.backoff_maximal
+        );
+        assert_eq!(
+            updated_config.mqtt.reconnect_after_expiry,
+            mqtt_default_cfg.reconnect_after_expiry
+        );
+        assert_eq!(
+            updated_config.mqtt.certificate_file_path,
+            mqtt_default_cfg.certificate_file_path
+        );


nit: I think it would be more readable if you would create the expected struct and compare it against the updated_config, instead of manually doing it field by field.

Agreed, changed

tomaszklak · 2024-12-12T10:27:54Z

clis/teliod/src/qnap.rs

+
+        let update_body = r#"
+        {
+            "authentication_token": "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"


Please add tests for all the fields.

wdym? Add tests for each field partial update?

or changing all fields in a single test is enough?

The important part is that the whole production code is covered - whether it's in one test or many is less important and I will leave this up to you to judge which is better in this case.

clis/teliod/QNAP.md

tomaszklak · 2024-12-18T11:11:53Z

clis/teliod/Cargo.toml

@@ -34,6 +34,13 @@ anyhow.workspace = true
 smart-default = "0.7.1"
 base64 = "0.22.1"
 dirs = "4.0.0"
+const_format = { version = "0.2.33", optional = true }
+rust-cgi = { version = "0.7.1", optional = true }
+arrayvec = "0.7.6"


This doesn't seem to be used anywhere - please remove it.

tomaszklak · 2024-12-18T11:16:12Z

clis/teliod/src/qnap.rs

+        (&Method::POST, _) => start_daemon(),
+        (&Method::DELETE, _) => stop_daemon(),
+        (&Method::PATCH, _) => {


Ugh.... I meant query not path 🤦

tomaszklak · 2024-12-18T11:24:28Z

clis/teliod/src/qnap.rs

+fn kill_teliod_process() -> Result<(), io::Error> {
+    match fs::read_to_string(PID_FILE) {
+        Ok(pid) => {
+            let _ = Command::new("kill").arg("-9").arg(pid.trim()).status();


Yeah, I'm thinking that maybe we shouldn't be calling kill at all - it might turn out it's possible somehow to trick our cgi handler to kill arbitrary processes on qnap.

tomaszklak · 2024-12-18T11:27:31Z

clis/teliod/src/qnap.rs

+    } else {
+        match kill_teliod_process() {
+            Ok(_) => text_response(StatusCode::OK, "Application stopped successfully."),
+            _ => text_response(StatusCode::GONE, "Application not found."),


Might be good to log the error somewhere, or include it in the response.

kill_teliod_process function removed

tomaszklak · 2024-12-18T11:28:03Z

clis/teliod/src/qnap.rs

+        text_response(StatusCode::OK, "Application stopped successfully.")
+    } else {
+        match kill_teliod_process() {
+            Ok(_) => text_response(StatusCode::OK, "Application stopped successfully."),


I think it would be best not to use the same exact message here and in the ok case.

kill_teliod_process function removed

tomaszklak · 2024-12-18T11:32:06Z

clis/teliod/src/qnap.rs

+fn stop_daemon() -> Response {
+    if shutdown_teliod().is_ok() {
+        text_response(StatusCode::OK, "Application stopped successfully.")
+    } else {


Let's not ignore this error and include it in below messages or log it somehow.

Added shutdown error log

tomaszklak · 2024-12-18T11:40:25Z

clis/teliod/src/qnap.rs

+
+    #[test]
+    fn test_update_config() {
+        let _lock = TEST_SEQ_MUTEX.lock().unwrap();


This can be replaced with serial_test, which we already use across other crates in libtelio.

tomaszklak · 2024-12-18T11:41:41Z

clis/teliod/src/qnap.rs

+        configure_interface::InterfaceConfigurationProvider,
+    };
+
+    pub const TELIOD_CFG: &str = "/tmp/teliod_config.json";


I think this will fail on windows - can you change it to use https://crates.io/crates/tempfile ?

I think this is out of scope for now, we can make this as an issue, to make cgi standalone and cross platform

This is not about making cgi cross platform - it's about making unit tests pass for developer(s?) on windows.

How would windows devs run these unit tests?

Hm, you right - there is no configurability in this module and all paths are completely hardcoded. It's probably relatively cheap to make paths be configurable with a prefix (which would be empty in production) and set it to temporary dir in tests. But fell free to treat this thread as nitpick and ignore it if you want.

clis/teliod/src/qnap.rs

Original work done in #1012. This is restructure and reabase on common base.

Jauler · 2024-12-20T14:32:51Z

clis/teliod/src/command_listener.rs

@@ -76,6 +76,19 @@ impl CommandListener {
                })
                .await
            }
+            ClientCmd::QuitDaemon =>


IMHO it would be nice to log commands executed (e.g. debug!() or maybe info!()). This helps puts things into perspective when debugging various issues.

Obviously - we should log all commands not just QuitDaemon. Although it does not have to be this PR, it may be separate one

Every command received by the daemon is logged here.

Jauler · 2024-12-20T14:46:31Z

clis/teliod/src/configure_interface.rs

 #[serde(rename_all = "lowercase")]
 pub enum InterfaceConfigurationProvider {
+    #[default]
    Manual,
    Ifconfig,
    Iproute,


This is just an idea, so you may resolve this message once you have read it.

Eventually it would be really nice to use netlink for network configs instead of spawning shell commands :).

I think is a good idea but out of scope of this PR :)

Jauler · 2024-12-20T14:48:38Z

clis/teliod/src/config.rs

+
+fn deserialize_partial_authentication_token<'de, D: Deserializer<'de>>(
+    deserializer: D,
+) -> Result<Option<String>, D::Error> {


Maybe it would be worth creating dedicated type for Authentication Token? This would allow us to do some type-safe things (e.g. derive zeroize and similar). Restrict printing/logging and similar. Reliably enforce invariants (e.g. hexdigits only and 64 lengh max)

That was my initial thought, I've changed my mind though when I realized the effort and started to go out-of-scope of the PR. This is definitely a TODO for the next PRs.

Jauler · 2024-12-20T14:59:41Z

clis/teliod/src/qnap.rs

To make sure that feature qnap does not accidentally leak out of the feature, would it make sense to mark all of this file as #[cfg(feature = "qnap")]?

Didn't fully understand what you mean with "leak out of the future". Anyways, this tree structure will change in the next PR so I think is trivial

Jauler · 2024-12-20T15:03:59Z

clis/teliod/src/main.rs

@@ -96,13 +105,21 @@ async fn main() -> Result<(), TeliodError> {
            if DaemonSocket::get_ipc_socket_path()?.exists() {
                Err(TeliodError::DaemonIsRunning)
            } else {
+                #[cfg(feature = "qnap")]
+                let _pid_guard = qnap::PidFile::new().await?;


I wonder do we have a need for pidfiles?

That's the pattern used for QNAP applications, for start/stop routines (eg: qnap/shared/NordSecMeshnet.sh).

good point, initially we were killing the process from the cgi script, which was in the meantime removed and we don't need the Pidfile now.. so will remove Pidfile from the app side.

Jauler · 2024-12-20T15:07:36Z

clis/teliod/src/main.rs

                    debug!("Overriding token from env");
-                    config.authentication_token = t;
+                    if token.len() == 64 && token.chars().all(|c| c.is_ascii_hexdigit()) {


It would be nice to make AuthorizationToken type which would enforce these invariants. e.g. something on the lines like:

struct AuthorizationToken { ... }; impl AuthorizationToken { pub fn new(String token) -> Result<Self, Error> { if token.len() != 64 || token.chars().all(|c| c.is_ascii_hexdigit()) { return Err(...); } ... } }

And then every place, which needs access to AuthorizationToken would use AuthorizationToken struct instead of String. The benefit of such approach is that we can be sure (in a type safe manner) that invariants (e.g. length and symbol requirements) are always enforced for such type and makes it significantly harder to forget validation by accident. What is more, there it reduced code repetition, as even this length and hexdigit requirement had to be replicated a few times in current PR.

I had pretty much the same thought here: https://github.com/NordSecurity/libtelio/pull/1012/files#r1894030576

Agreed! However this will be part of the next PR.

clis/teliod/src/daemon.rs

clis/teliod/src/qnap.rs

stalowyjez · 2024-12-20T14:49:48Z

clis/teliod/src/qnap.rs

+const QPKG_DIR: &str = "/share/CACHEDEV1_DATA/.qpkg/NordSecurityMeshnet";
+const TELIOD_BIN: &str = concatcp!(QPKG_DIR, "/teliod");
+const MESHNET_LOG: &str = concatcp!(QPKG_DIR, "/meshnet.log");
+const TELIOD_LOG: &str = "/var/log/teliod.log";


I don't think this should be called "teliod log", as teliod logs with meshnet logger

Hm.. what do you mean with "teliod logs with meshnet logger"?

I mean it uses tracing logs as Telio, so all of them go to the same file. Here there is the initialization for both meshnet and teliod:

libtelio/clis/teliod/src/daemon.rs

Line 184 in 26fe43a

tracing_subscriber::fmt()

it doesn't really use stdout for logging (or it shouldn't at least)

We have meshnet logs (from libtelio) which use the tracing crate and then we have teliod logs which log the stdout/stderr of the teliod process.

The link you shared has tracing object initlization for meshnet logs, however you say both meshnet and teliod? I don't understand

clis/teliod/src/qnap.rs

stalowyjez · 2024-12-20T15:05:00Z

clis/teliod/src/qnap.rs

+            )
+        }
+    };
+    match Command::new("setsid")


imho it would be nicer to fork than using cli

fork() is still used, however when used alone, the child process inherits the parent session id which makes the process quit after the parent session ends. Instead setsid sets a new session id for the child process.

https://man7.org/linux/man-pages/man2/setsid.2.html

I meant sth like we had in Tcli, it worked well

Can you be more specific pls?

Jauler · 2024-12-20T15:23:44Z

clis/teliod/src/qnap.rs

+    }
+}
+
+fn get_meshnet_logs() -> Response {


Is there a good reason to separate teliod and meshnet logs? maybe it would be worth to interleave them, like apps do? In that case it is slightly easier to get them from users, as there is single file instead of two.

In my POV I'd prefer to keep them separated simply because meshnet logs will bury teliod logs (too many meshnet logs) which also convey a different category of information.

lcruz99 requested a review from a team as a code owner December 4, 2024 17:56

lcruz99 force-pushed the LLT-5831_move_cgi_logic_to_teliod branch from 4d75c96 to 03917df Compare December 4, 2024 18:06

lcruz99 temporarily deployed to Internal December 4, 2024 18:06 — with GitHub Actions Inactive

lcruz99 force-pushed the LLT-5831_move_cgi_logic_to_teliod branch from 03917df to 38938fe Compare December 4, 2024 20:49

lcruz99 temporarily deployed to Internal December 4, 2024 20:49 — with GitHub Actions Inactive

stalowyjez reviewed Dec 5, 2024

View reviewed changes

packgron reviewed Dec 9, 2024

View reviewed changes

ghztomash reviewed Dec 10, 2024

View reviewed changes

lcruz99 force-pushed the LLT-5831_move_cgi_logic_to_teliod branch from 38938fe to 0abc522 Compare December 10, 2024 18:46

lcruz99 temporarily deployed to Internal December 10, 2024 18:47 — with GitHub Actions Inactive

lcruz99 force-pushed the LLT-5831_move_cgi_logic_to_teliod branch from 0abc522 to 687836b Compare December 10, 2024 18:52

lcruz99 temporarily deployed to Internal December 10, 2024 18:52 — with GitHub Actions Inactive

lcruz99 force-pushed the LLT-5831_move_cgi_logic_to_teliod branch from 687836b to a21cb40 Compare December 11, 2024 14:53

lcruz99 temporarily deployed to Internal December 11, 2024 14:53 — with GitHub Actions Inactive

lcruz99 force-pushed the LLT-5831_move_cgi_logic_to_teliod branch from a21cb40 to 4cd24a8 Compare December 11, 2024 15:42

lcruz99 temporarily deployed to Internal December 11, 2024 15:42 — with GitHub Actions Inactive

lcruz99 force-pushed the LLT-5831_move_cgi_logic_to_teliod branch from 4cd24a8 to 2608ac7 Compare December 11, 2024 15:54

lcruz99 temporarily deployed to Internal December 11, 2024 15:54 — with GitHub Actions Inactive

lcruz99 force-pushed the LLT-5831_move_cgi_logic_to_teliod branch from 2608ac7 to 5f8d630 Compare December 11, 2024 16:22

lcruz99 had a problem deploying to Internal December 11, 2024 16:22 — with GitHub Actions Failure

lcruz99 temporarily deployed to Internal December 11, 2024 16:24 — with GitHub Actions Inactive

lcruz99 force-pushed the LLT-5831_move_cgi_logic_to_teliod branch from 5f8d630 to 2657c32 Compare December 11, 2024 16:25

lcruz99 temporarily deployed to Internal December 11, 2024 16:25 — with GitHub Actions Inactive

packgron reviewed Dec 12, 2024

View reviewed changes

tomaszklak requested changes Dec 12, 2024

View reviewed changes

lcruz99 changed the title ~~[LLT-5831] Move cgi logic to teliod~~ [LLT-5831] QNAP: move cgi logic to teliod Dec 12, 2024

lcruz99 requested a review from packgron December 17, 2024 15:42

packgron reviewed Dec 18, 2024

View reviewed changes

clis/teliod/QNAP.md Outdated Show resolved Hide resolved

lcruz99 force-pushed the LLT-5831_move_cgi_logic_to_teliod branch from f28351d to e88801f Compare December 18, 2024 11:35

lcruz99 temporarily deployed to Internal December 18, 2024 11:35 — with GitHub Actions Inactive

tomaszklak reviewed Dec 18, 2024

View reviewed changes

lcruz99 force-pushed the LLT-5831_move_cgi_logic_to_teliod branch from e88801f to 97e2acd Compare December 18, 2024 11:51

lcruz99 temporarily deployed to Internal December 18, 2024 11:51 — with GitHub Actions Inactive

packgron reviewed Dec 18, 2024

View reviewed changes

clis/teliod/src/qnap.rs Outdated Show resolved Hide resolved

packgron added a commit that referenced this pull request Dec 18, 2024

teliod cgi: Add base api to control teliod daemon

6a8b7f6

Original work done in #1012. This is restructure and reabase on common base.

packgron added a commit that referenced this pull request Dec 19, 2024

teliod cgi: Add base api to control teliod daemon

dc45504

Original work done in #1012. This is restructure and reabase on common base.

lcruz99 force-pushed the LLT-5831_move_cgi_logic_to_teliod branch from 97e2acd to a696f1e Compare December 19, 2024 18:32

lcruz99 temporarily deployed to Internal December 19, 2024 18:32 — with GitHub Actions Inactive

Jauler reviewed Dec 20, 2024

View reviewed changes

stalowyjez reviewed Dec 20, 2024

View reviewed changes

Jauler reviewed Dec 20, 2024

View reviewed changes

qnap: Use QNAP predefined binary paths

7b3376f

lcruz99 force-pushed the LLT-5831_move_cgi_logic_to_teliod branch from a696f1e to e58d335 Compare December 20, 2024 15:51

lcruz99 temporarily deployed to Internal December 20, 2024 15:51 — with GitHub Actions Inactive

lcruz99 added 5 commits December 20, 2024 15:53

qnap: Implement cgi logic in teliod

f548cb0

qnap: Add REST API documentation

4e2feb3

teliod: Stop quitting daemon if invalid command received

9497a29

teliod: Add command for daemon graceful shutdown

3ebd8cb

teliod: Add isAlive command for runtime query

bf4f507

lcruz99 force-pushed the LLT-5831_move_cgi_logic_to_teliod branch from e58d335 to bf4f507 Compare December 20, 2024 15:53

lcruz99 temporarily deployed to Internal December 20, 2024 15:53 — with GitHub Actions Inactive

[LLT-5831] QNAP: move cgi logic to teliod #1012

Are you sure you want to change the base?

[LLT-5831] QNAP: move cgi logic to teliod #1012

Conversation

lcruz99 commented Dec 4, 2024 • edited Loading

Problem

Solution

☑️ Definition of Done checklist

tomaszklak commented Dec 5, 2024 • edited Loading

stalowyjez left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lcruz99 Dec 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lcruz99 commented Dec 5, 2024 • edited Loading

lcruz99 commented Dec 5, 2024 • edited Loading

stalowyjez commented Dec 6, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Jauler Dec 20, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Jauler Dec 20, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lcruz99 Dec 20, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lcruz99 Dec 20, 2024 • edited Loading

Choose a reason for hiding this comment

lcruz99 commented Dec 4, 2024 •

edited

Loading

tomaszklak commented Dec 5, 2024 •

edited

Loading

lcruz99 Dec 5, 2024 •

edited

Loading

lcruz99 commented Dec 5, 2024 •

edited

Loading

lcruz99 commented Dec 5, 2024 •

edited

Loading

Jauler Dec 20, 2024 •

edited

Loading

Jauler Dec 20, 2024 •

edited

Loading

lcruz99 Dec 20, 2024 •

edited

Loading

lcruz99 Dec 20, 2024 •

edited

Loading

lcruz99 Dec 20, 2024 •

edited

Loading