ogClient can receive events via a datagram socket opened at 55885.
This socket is only opened when in windows or linux mode, for
event reporting from within the system.
Events reported this way are sent back to ogServer via a 103 Early
Hints HTTP message. Information regarding the event is sent in the
response's payload.
Windows does not report a refused connection the same way as Linux.
Unsuccesful connect socket will be kept in the exceptfds, and won't
be in the readable nor writable fds. The socket in this state will
have SO_ERROR set to ECONNREFUSED.
On the other hand, Linux does not use exceptfds for such case.
If current platform is Linux (either live, virtual or linux) expect
/opt/opengnsys/ogclient/cfg/ to contain ogclient.json.
If current platform is not Linux then we fallback to current directory.
Add agent mode for windows platform.
Subprocess module for shell/run is cross-platform an no change was
needed. The subprocess will run with the same privilege as its parent,
ogclient.
TODO: Provide a windows installer. As of now, an administrator
needs to install python and required libraries for this mode to be
usable.
ogClient can run in "linux" mode. In addition to live or virtual.
Serves as a substitute to the legacy ogagent, which has not received any
updates since 2020/07/23.
Linux mode initially supports remote reboot and poweroff. Requires
updated ogServer with the Linux ogclient state.
ogClient can be set up to run in linux mode by specifying it in
ogclient.json:
{
"opengnsys": {
"ip": "192.168.56.10",
"port": 8889,
"log": "DEBUG",
"mode": "linux",
...
}
Abort command if the connection with the server is lost.
Otherwise, a race condition that leaves ogServer and ogClient
out-of-sync might occur:
1. ogClient is busy running a command (on the worker thread), for example,
image/restore.
2. ogServer is stopped OR ogClient loses connection with ogServer (due to
transient network problem).
3. ogClient reconnects and ogServer sends a refresh command.
4. ogClient worker thread finishes and it sends a reply to image/restore.
5. ogServer gets confused because it expects a reply to the refresh
command, not the old image/restore.
If server closes the connection, close the socket, reconnect and stop
processing. self.connect() already cleans up the internal state, including the
socket state.
OgClient miscalculates the body size of the request.
ogServer delimits HTTP headers with "\r\n\r\n" to comply with RFC 2616.
But ogClient searches for the first "\r\n" delimiter, hence, ogClient
stops at the first HTTP header field instead of at the end of the header.
Hence, it incorrectly assumes the body starts after the first "\r\n".
This commit updates ogClient to search for the "\r\n\r\n" delimiter.
Example:
POST /shell/run HTTP/1.1\r\n <-- ogClient considers body starts here (WRONG!)
Content-Length: 952\r\n
Content-Type: application/json\r\n
\r\n <-- Here is where the body starts
{"json-body":...}
Irina reports that "Partition assistant"/"Asistente de particionado" is
not working. This is happening because ogClient is not reading the full
data ogServer sends when the entire HTTP PDU is larger than 1024.
However, ogClient should read the whole message, reading until read data
length is greater or equal to "Content-Length" header value.
ogClient fails to obtain "Content-Length" value because is looking for
"content-length", be aware of the case sensitivity. It also needs to
take into account the header length because read data length also
includes headers.
This patch updates ogClient to:
1) look for "Content-Length instead of "content-length".
2) compare read date length with content length plus headers
length.
Disconnect gracefully from ogServer after booting OS, the script to start the
OS calls kexec, so everything is gone after it. For Windows, this results in a
reboot.
This commit also improves the disconnect function to make sure the
disconnection is synchronous.
ogAdmClient has a support for initializing the session in the machine. This new
command allows the new ogClient to execute the same script to init the session.
The arguments will be received from the server as a json message. Format:
{ "disk" : "0", "partition" : "1"}
Opengnsys needs a support to execute commands on the machine. This patch adds
the support for executing two new commands "shell/run" and "shell/output". The
first one, give us the support for executing a command in the machine and keep
save in a queue the output. The second one, give us the support for sending the
output from the command executed.
To disconnect the socket or send a message we use in different parts of the code
the attribute socket which is declared inside of the client. This way will
create us important problem in the future if we want to change the behavior in
our client sockets. This patch adds two new methods inside the client and we
can use them in other classes giving us the easy way to send messages and
disconnect the client.
Our program sends always the HTTP message:
HTTP/1.0 200 OK
but if the operation sent is not supported, we are sending the same correct
message. This patch add the support to check if the message is supported.
If the message is not supported, we are going to send:
HTTP/1.0 400 Bad request\r\n\r\n
Otherwise, in operations supported:
HTTP/1.0 200 OK
The new OpenGnsys support to communicate server and client side will be
HTTP. This new class allows us the support for parsing all the message received
from the server in HTTP format.
During our connections, we are using states to control the Client Socket. We
defined using global variables. In case that we modify this global variable,
we need to change it in serveral parts of the code.
Using enums and declaring a new class, we can redefine the values or create new
states without changing the same code in differents python files.
Jose M. Guisado
OpenGnSys Support Team
Javier Sánchez Parra
Roberto Hueso Gómez
Roberto Hueso Gomez
Alvaro Neira Ayuso