erik/converge
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

updated the about page

Browse Source
This commit is contained in:
Erik Brakkee 2024-08-13 00:50:54 +02:00
parent df9409fc75
commit cb03b79630
1 changed files with 34 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
pkg/server/templates/about.templ
View File

@ -75,7 +75,23 @@ templ About() {
having to start over again.
Using authorized keys is made easy through the
<a href="usage.html">usage</a> page, which provides the exact commands to execute based
on the target environmnet.
on the target environmnet. If users are hesitant to use their public key it is also possible
to generate a separate ssh key-pair using <code>ssh-keygen</code> and use that instead.
</p>
<p>To be able to use Converge, you must already have access to the configuration of a build job.
Having that access means it is possible to execute any command on a build agent. The Converge
agent is started by the build job and does not have any additional rights compared to what you
could script in the continous integration job definition.
</p>
<p>Converge does not provide any stealth features to hide it. The public sessions page show all
agents and clients including details about the clients and the agents. The idea is that it should
be light-weight and easy to use. There is no reason to hide the fact that someone is debugging
a continuous integration job. Also, all activity is logged,]both using standard kubernetes tooling
such as (fluentbit/filebat, and loki/elasticsearch depending on the environment). Also, Converge
provides a prometheus metrics endpoint which allows user sessions to be tracked over time after
the fact. Thie data is also made accessible using a grafana dashboard.
</p>
<h2>SSH and SFTP</h2>
@ -90,8 +106,14 @@ templ About() {
There is a timeout mechanism in the agent such that jobs do not hang indefinitely
waiting for a connection. This mechanism is useful to make sure build agents do not keep
build agents occupied for a long time. By default, the agent exits with status 0 when
the first client exits after logging in. The timeout is an inactivity timeout which is reset
every time the user presses a key on the keyboard.
the first client exits after logging in. The timeout is an inactivity timeout. Activity is
detected as follows:
<ul>
<li><b>ssh</b>: any key press is considered activity</li>
<li><b>sftp</b>: any output from the server side is considered activity. This is done to
make sure that longer downloads cannot be killed by a timeout. A simple <code>ls</code> command
in an sftp session will also lead to activity since the server will output the result of the command. </li>
</ul>
</p>
<p>When the user touches a .hold file, the agent keeps waiting for connections even
after the last client logs out, taking into account the timeout. By default the agent
@ -108,10 +130,14 @@ templ About() {
</p>
<p>
The agent sets a <coder>agentdir</coder> environment variable that points to
The agent sets an <coder>agentdir</coder> environment variable that points to
the directory where the agent is running.
</p>
<p>The user will get notifications from the agent any time something important happens such
as the session being close to timeout.
</p>
<h2>other tools</h2>
<p>Using available existing tools such as
@ -125,12 +151,12 @@ templ About() {
<p>
<ul>
<li>Breakpoint uses an embedded SSH server which is a really good idea but
uses the QUIC protocol for connecting to a rendez-vous server. The rendez-vous server than
uses the QUIC protocol for connecting to a rendez-vous server. The rendez-vous server then
exposes a random port for every client. This make deployment on kubernetes really hard
where fixed ports must be used and QUIC is also not a widely supported protocol.</li>
<li>The problem with the random ports can be solved by using wstunnel running together
with breakpoint server in a kubernetes pod, where wstunnel can forward traffic over an
extern websocket connection to the local random port that breakpoint server is listening on.</li>
external websocket connection to the local random port that breakpoint server is listening on.</li>
<li>breakpoint leaves it open on how users install the breakpoint executable (agent). </li>
<li>Because of the hacky nature of this setup, it is very difficult for users to use
and troubleshoot when things go wrong. </li>
@ -154,11 +180,11 @@ templ About() {
<li>User-friendly error messages can be given to users in most case when things do not work
out because of <code>wsproxy</code>, an SSH proxy command that also talk to the server
to tell the user if a connection is accepted and if not why not. </li>
<li>A live screen showing the current sessions that are running. The sessionw webpage provides
<li>A live screen showing the current sessions that are running. The sessions webpage provides
additional feedback about the running sessions. </li>
<li>Interactivity in the user's session with notifications about timeouts and a very
simple inactivity timeout mechanism. </li>
<li>Possibility for the user to define his own shell. </li>
<li>Possibility for the user to define the remote shell to use. </li>
<li>Support for unix like bash shells and command prompt and powershell. </li>
</ul>
<p>