Containerization is an awesome next-step forward when it comes to deploying services and applications reliably without needing to worry about the intricacies of adding dependencies and configuring environments. One can easily deploy, utilize, upgrade and remove these with just a few lines of commands and the unintrusiveness nature of the containers is almost very rewarding for the sysadmins — now that they do not have to worry about taking care of the residual configurations!

Although observability of such containers is an entirely different story, due to the fact that every container is a disjoint system in its own right with a lot of configuration variables to consider, performance statistics to study and execution histories to read through. Having all such complexities to think about could potentially lead to the creation of a very convoluted tool that may make system monitoring look overwhelming to the users — that is something I tried to address with this service of mine.

The earliest commit made to this project was about three months ago, but it has been something I have been conceptualizing forever. SuperVisor is a combination of two services — the first is a driver service which monitors the container station system deeply and dispatches metrics, while the second is a frontend service which takes up the metrics served by the former and parses them in an interactive and functional dashboard.

How do I set it up at my end?

You would really want to take it for a spin if you liked what you saw above. Setting up SuperVisor on a Docker station is literally as easy as following the provided three steps in sequence.

Step #1
Run the following commands to start up the driver service and take a note of sync URI, termsocket URI and passcode carefully.

docker run -d \
  --restart unless-stopped \
  --name supervisor-driver-service \
  -p 8888:8888 \
  -p 6969:6969 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  t0xic0der/supervisor-driver-service:v1.1.0b-amd64

docker logs supervisor-driver-service

 ,---.                    .    ,o               
 `---..   .,---.,---.,---.|    |.,---.,---.,---.
     ||   ||   ||---'|     \  / |`---.|   ||    
 `---'`---'|---'`---'`      `'  ``---'`---'`    
           |
 * Driver Service v1.1.0-beta
 * IP version        : 4
 * Passcode          : 6097A8C00A2BC97C
 * Sync URI          : http://0.0.0.0:8888/
 * TermSocket URI    : http://0.0.0.0:6969/
 * Monitor service   : Psutil v5.8.0
 * Container service : DockerPy v4.4.1
 * WebSocket service : Terminado v0.9.2
 * Endpoint service  : Falcon v2.0.0
 * HTTP server       : Werkzeug v1.0.1
 * Running on http://0.0.0.0:8888/ (Press CTRL+C to quit)
 * TermSocket started on port 6969

Step #2
Run the following command to start up the frontend service and head over to http://<HOSTNAME>:9696/using a browser of your choice.

docker run -d \
  --restart unless-stopped \
  --name supervisor-frontend-service \
  -p 9696:9696 \
  t0xic0der/supervisor-frontend-service:v1.1.0b-amd64

Step #3
Now enter the sync URI, termsocket URI and passcode which you acquired from the first step and enter them in the login page to get started. Do not copy the ones provided above as they are here just for representation.

You will be welcomed by the dashboard page which lists all the available containers, images, networks and volumes. From there on, I would recommend exploring further to see what SuperVisor is capable of!

In action

Here are some screenshots which might convince you to give it a try if you are not already 😁

Epilogue

Find the frontend service here https://hub.docker.com/r/t0xic0der/supervisor-frontend-service and the driver service here https://hub.docker.com/r/t0xic0der/supervisor-driver-service — images would be actively published here on every release.

As this is a beta testing release, bugs would be actively sorted out and features would be constantly added in — so criticisms, praise, advice and everything else are most welcome! If you like what you saw here, please go ahead and star these repositories to show your support and motivate me https://github.com/t0xic0der/supervisor-frontend-service/ and https://github.com/t0xic0der/supervisor-driver-service/.

Imagine situations when…

• You want to send evidence to the human resource department about workplace harassment but you run the risk of losing your job if you are discovered doing so!
• You have lost all your communication equipment on a secret mission though you need to dispatch a directive securely to your units without anybody else taking a peek!
• You are talking to your sweetheart and suddenly their phone is snatched away — There is probably no way for you to get rid of all conversations from both the sides!

TL;DR

I have created a secure synchronous lightweight chatroom web application with the following features -

• Provides real-time conversation using synchronous sockets
• Zero logging or data storage to minimize vulnerabilities
• No-frills alias and password-protected chatroom creation
• Refresh, close tab, logout or purge chatroom to cover tracks
• Transient chatrooms stay valid for 60 minutes before auto-purge
• Complete support for HTML5 formatting tags in conversations
• Lightweight and responsive so usable across multiple devices
• State-of-the-art chatroom user session management

You can find the repository here

Sanctuary by t0xic0der

Using stuffs like

• Socket.IO for real-time, bidirectional and event-based communication
• Flask for web backbone, complex scalability and WSGI layer
• Hashing techniques for password protection, identification and authentication

Why would I need a tool like this?

• There are not many no-frills messaging applications out there.
• All platforms gather your data and footprints are recorded.
• Most platforms would want you to register at their platform first.
• Application would also require resources for installation.
• All conversations are mostly logged in remote servers.
• Cryptography used in encrypting your messages is not reliable.
• There is no way to maintain anonymity during conversations.

Okay, I’m listening…

Glad that you are listening!

I have created a platform hosting lightweight and protected chatrooms for secure synchronous conversations where no data is logged and there is total transience. Using synchronous sockets, I was able to provide for real-time messaging. There are less chances of impending vulnerabilities or risks on data breach as literally nothing is being stored. Being a web application, it does not require any kind of offline installation.

The no-frills nature of it requires you to provide just an alias — a false identity — and a chatroom name and password to get started. Just enter a secure password of your own and you will be granted with a chatroom link. The chatroom can exist for as long as 60 minutes before self-destructing. You can of course prematurely purge it!

When the chatroom is created, all you need to do is share the link and the password to it with your allies so that they can roll in for some secure conversation. They can join, chat and leave anytime within the valid duration as many times as they want. As there can be many chatrooms with the same name, special care has been taken to distinguish between them.

Now, that you have joined the room — you can chat with the participated members. To spice things up, I have added full support to HTML5 tags so you can extend your experience by sharing images, videos and documents using them. The following can be done from within the chatroom to maintain total safety.

• You can refresh the page to get rid of all messages at your end while staying in the chatroom.
• You can logout from the room to get rid of all messages at your end while leaving the chatroom.
• You can purge the chatroom to get rid of all messages from all the ends while kicking everyone from the chatroom.

You can of course logout from the room if you are done with your part of the conversation but this would remove all the conversations only from your end. Once this action is performed, the session is invalidated and you cannot backtrack your way to the chatroom unless you decide to log back in again to continue.

On chatroom purge, all conversations are removed from all the ends and every participant is removed from the chatroom. The chatroom is then destroyed — meaning that nobody else can join the chatroom henceforth. This capability is given to every participant as there is no telling that which side can be compromised.

Well, there would always exist people who like to indulge in the monkey business of finding their way into expired and invalidated sessions. With the state-of-the-art session management system and user-chatroom bind, I was able to create a robust and secure protection for the chatrooms. This is how it would show up when you do the undone.

What are your future plans?

I am planning to build myself a gaming PC — fully equipped with twin RTX2080Tis and get into the streaming business full-time because ….

Hold on! I am asking about the future of this project

Oh my bad!

The project is currently in its infancy. Bugs are discovered and fixed everyday. New feature requests are made and worked upon continually. It would be sometime before this thing becomes production ready but that definitely does not mean you cannot try it. In fact I would encourage you to do so.

If you end up liking my work, I would ask you give stars to it and fork it so that you can contribute to the development of the project. This project has been free and it will always be.

You can find the repository here

Sanctuary by t0xic0der

Originally published at https://dev.to on April 16, 2020.