I'm developing a firmware updater that should download data from a web server and upload it to an Embedded Linux device.
I want a program (client) to start another program (server) before establishing a connection between them and start sending the data. To do that in the same environment is easy: just call QProcess and startDetached(), but I want to do that remotely: I want to start the client in the Desktop machine and, with the device connected via ETH/TCP in a known IP address, click a button which will ask the device to start the server. When the server finishes starting and start waiting for connections, the Desktop app will then open the socket connection and start sending the data. After all data have being send, another command should be send to ask the server to shut down, closing the connection and finishing the file transfer operation.
My question is: how can I do this operation of asking for an application to either start or stop when it is located in a different machine (in an Embedded Linux device while the caller is in a PC)? Notice that the solution must be such that doesn't depend on some extra software (such as a Tcp server) to constantly run on the device - that's precisely what I'm trying to avoid.
This is not related to Qt in any way, because it doesn't provides anything for that purpose.
There are at least two paths from this point:
use SSH from your application to start any process in the remote machine: ssh user#remote-machine "any command here". This can be called using QProcess;
or
write another software to listen to socket commands and start/stop any process you want, then get it running all the time in the remote machine. Then, it's just a matter of changing your client software to send the relevant commands
Beware of any security issue that may arise by allowing the machine to execute arbitrary commands from external sources.
Related
Build: Server with Ubuntu 18.04 in data center with Ubuntu Mate Desktop interface.
As I understand, any GUI app needs a display in which to function. I connect to the server via x2go to display the ubuntu mate interface.
Once connected, I have a scheduled cron job that launches a terminal, a GUI and some commands.
Everything works perfect as I have previously detected what display I'm using as a user and specify that to launch the terminal and the commands.
Problem: if I'm not connected via x2go client to the server and provide that display, I noticed today that the cron job didn't launch at the specific time (08:50), which was previous to my x2go client connection (09:23); it just launched when I did the x2go client connection from my desktop manually -- my understanding is that it didn't launch because there was not any available display.
I'm not technical enough to get more deep into this problem.
¿Is there anyway in which I can make the cron script function (i.e. that it launchs the terminal and the GUI) without the need of manually getting into my desktop and launching the remote desktop client (x2go)?
My ideas go for having another minimal setup in that data center or another that takes the advantages of being there and have a physical monitor to display constantly connected to the main server OR just manually entering the server via x2go every day.
EDIT: When I disconnect the x2go client session from the server, the launched GUI and etc perfectly maintains, without dissapearing because "I have terminated the session and eliminated the display".
Finally got it working with the great help of one of x2go founders (Oleksandr Shneyder) after understanding how x2go handles the sessions and the X server.
Sessions can suspended/hibernated, disconnected and terminated.
Suspended/hibernated: when "manually" or automatically the x2go server side suspends so that it saves resources.
Disconnected: when you exit the session window and the x2go client in your desktop/laptop.
Terminated: when you log out from the DE environment or issue the x2goterminate-session command in the terminal inside the session.
My x2go app was somehow entering into suspending mode in the server, causing that the display (50 in my case) in which the scheduled cronjob need to be run and launche the GUIs, "was not awaken" until I entered into the session via the
app. In that moment, the cronjob started executing.
To tell x2go server to not hibernate, I needed to change the X2GO_NXOPTIONS in /etc/x2go/x2goagent.options to X2GO_NXOPTIONS="sleep=0"
After this, everything functions perfectly in the server.
Hope it helps others.
I have several Linux (mostly Debian) servers running on a Proxmox platform. All of them connecting to Internet through an ADSL line, with only one public IP.
One of them is running OMD (open monitoring distribution) since longer than a year ago to monitor an EXTERNAL server (other network, monitored through that ADSL connecting to Internet.
Now I have received a message from the owners of the remote server saying that they have detected a port scan run in the night from my ADSL public IP scanning their open ports.
It's the second time this happens to me with a Debian system :(
I need to detect the process running that scan
how can I find out what process is launching that portscan from the offending linux box? The difficulty here is that I'd need to run -whatever- to know the process when the scan takes place -which can happen at some moment in the night-.
Is there a way to get a list of processes that have somehow being launched and then finished between two times (i.e. new processes started from 23:00 to 03:00)
Thanks in advance
I would recommend that you place an IDS (Intrusion Detection System) on your network in order to identify the offending system. Snort is a widely used IDS that would be suitable for the job. It would probably be easiest to configure a span port on your router to send all outgoing traffic to the IDS. The Snort rules you can download from their website will generate alerts if port scanning occurs.
While the IDS is running you should simultaneously monitor processes on the Linux systems you suspect to be conducting the unwanted scanning. A simple script could be created to save process listings at a time interval, or list unique processes discovered with timestamps. If something more professional is desired, I'm sure there is some sort of freely available process logging software.
Run the IDS and process monitoring overnight. Find the unwanted port scanning in the IDS alerts to identify the system. Cross-reference the time of the alert with the process logging in order to track down what is creating this traffic.
Good luck.
For some time now I've been trying to send files to a Embedded Linux device via FTP without success. I even previously put a question in SO talking about my problem, and I still haven't got any further in solving it.
One thing I noticed, though, is that most FTP examples in the web includes a server-client relationship; the client connects itself to the server that is constantly listening in some IP-Port and the file transfer begins. Now when studying the examples using QNetworkAcessManager to send a file (generally to HTTP), they never mentioned the "other side requirements", what is leading me to believe I'm missing the necessary FTP server running in my Embedded Linux device.
So my question is more like a confirmation of my suspicions: if I want to transfer a file from my Desktop to my device using FTP, do I need to have a FTP server constantly running on that device? If yes, how that should change my code? For instance, should I abandon QNetworkAcessManager in favour of a QTcpClient usage? IOW what else should I know to make the file transfer system work using Qt? (In fact should I even bother myself with FTP at all instead of just using a normal QTcpServer?)
FTP is a protocol with 2 parties, the client and the server. Both must comply to the specification of FTP before file transfer can take place.
So yes there has to be a FTP deamon (the server) running the on the other device.
It doesn't have to run constantly just whenever you want to transfer files.
What is the difference between daemon and service ? (In windows or Linux).
A daemon is a background, non-interactive program. It is detached from the keyboard and display of any interactive user. The word daemon for denoting a background program is from the Unix culture; it is not universal.
A service is a program which responds to requests from other programs over some inter-process communication mechanism (usually over a network). A service is what a server provides. For example, the NFS port mapping service is provided as a separate portmap service, which is implemented as the portmapd daemon.
A service doesn't have to be a daemon, but usually is. A user application with a GUI could have a service built into it: for instance, a file-sharing application.
For more details: https://askubuntu.com/questions/192058/what-is-technical-difference-between-daemon-service-and-process
Daemons are processes running in the background and are not in your face.They do certain tasks at set times or responds to certain events.
In Windows, daemons are called services.
Daemon
From wikipedia:
A daemon is a computer program that runs as a background process,
rather than being under the direct control of an interactive user.
For example you want to ping google.com. That means something in your OS should know how to handle the Domain name resolution. That is a daemon.
More to read : Berkeley Internet Name Daemon (BIND)
Service
That name comes from Client Server Model. It means that an application runs as a service on a server, and a client version of the application is used to access the service. For example an Apache HTTP server application is a service on a server and a Chrome Browser is a client on a PC.
More to read: Client Server Model
A daemon is a computer program that runs as a background process, rather than being under the direct control of an interactive user.
A daemon is a subset of services that always run in memory waiting to service a request.
For example - crond , ftpd ,etc
Whereas, a Service is a server application or set of applications that runs in the background waiting to be used, or carrying out essential task. They are basically called in inter-process communication.
For example - httpd
For capturing ssh sessions I use "script" command: "script -c 'ssh user#host' outfile". But I have no idea how to capture sessions to remote hosts, that connected over com(serial) port.
screen script -c 'screen /dev/ttyS0 57600' file
ends immediately with empty log. Both 2 functions that implemented in screen is necessary: ability to switch between opened sessions and ability to perform i/o to /dev/ttyS. I started develop some tiny utility to redirect stdin/stdout to /dev/ttyS but now it's so buggy and doesn't work yet.
First off, a terminal program, like minicom (or good-ol cu), as suggested by Laszlo, is needed to communicate with the remote system. Once you can get such a program to work, then screen can be brought into the picture. Note that this also requires a getty running on the remote computer's serial port. If it's an old-fashioned serial port, you may also need a special null-modem cable.
Screen can be used with such a connection to be able to move access of the session across terminals. However, it cannot be used to spawn more than one session with the remote server. That's because the program running on the serial port (getty) only supports a single session. In this case, the screen runs on the local machine, and the terminal-program session running within screen connects to the remote server. So, it is possible to have multiple screens, but just not more than one connected to the remote server over a single serial port.
With all of that said, serial ports can be used to network two machines, assuming both support the same serial-line networking protocol. Networking eliminates these restrictions.
To open an interactive terminal session to a COM port (/dev/ttyS*), you probably want to use a terminal emulator software, like 'minicom'.