DEV Community: schnipdip

Raisensu: A Lightweight License Management Application

schnipdip — Sun, 13 Sep 2020 18:30:55 +0000

Hello! I want to brag about a little application I wrote called Raisensu. Raisensu is a lightweight license management solution that allows System Administrators to track licenses in a small to medium sized enterprise.

The idea behind Raisensu was pretty simple - not every application needs a full stack front end web application with a robust and complex backend. Raisensu is lightweight in the sense it operates purely at the commandline level. It supports High Availability between monitoring services (Linux only). Raisensu has the capability of being pure stateless or a stateful application.

The backend is pretty simple. A single table is used to store licenses. Raisensu supports two backend databases: SQLite3 and Postgresql.

It's easy to get started with Raisensu; it only takes a few commands!

Raisensu is supported on both Linux and Windows. The benefit to running on Linux is having High Availability support with the monitoring tool. A service file can be created easily to enable HA.

https://github.com/schnipdip/Raisensu

As a note, I'm not a programmer by trade. I develop small applications to keep up with basic knowledge and terminology for future expectations in my job. If you see any bugs or want to add something please open up a feature. If you want to contribute you can issue a PR.

I hope this application can serve you well :)

Automating debug removal for Ansible YAML code with Bugspray

schnipdip — Mon, 27 Jul 2020 05:03:39 +0000

Backstory: I wanted to learn more about the philosophy behind debug in production and development. I am not a programmer by nature, so understanding the implementation of debug was a foreign concept to me. I researched and researched on best practices for implementing debug into production. The answer I got - "it depends". There is no one way to properly implement debug. It comes down to what your enterprise requirements are. Some programmers leave in non-intrusive and non-sensitive debug in production code. Some programmers believe all debug should be removed from production.

I designed a small application to fulfill the needs of having to mass remove or selectively locate useful debugs.

The program I came up with is called Bugspray.

https://github.com/schnipdip/Bugspray

Bugspray allows you to automate the mass removal of debug code from YAML files or you can selectively keep debug within your code. This reduces the amount of time needed to refactor your code when moving from dev to ops. It fits nicely within the devops pipeline.

So whatever your enterprise requirements, Bugspray can help!

Python: Subprocess or Paramiko?

schnipdip — Tue, 22 Oct 2019 00:45:17 +0000

Has anyone done a performance test on either of these for SSH? From what I have read, subprocess seems to perform better

Making a Windows Python Application to Manage Linux Ansible

schnipdip — Wed, 16 Oct 2019 21:59:13 +0000

Introduction

Purpose

The purpose of this project is to control a Linux Ansible controller through Windows.

Idea inception

The original idea originated from this trying to automate an IDAM solution called BeyondTrust. BeyondTrust wasn't meant to be automated, so it was a pretty daunting task through Ansible.

Proposed Solution

I wanted to create a solution for dumb users who aren't familiar with the Linux environment and for those who aren't familiar with Ansible. I wanted to create a Windows solution, since most people are familiar with Windows and know how to double-click an executable.

Why Python?

Libraries

One of the main reasons I love using Python is for their extensive library selection. I know that if I have thought of something I want, someone has most likely already found a solution.

The libraries I am using are located below:

import tkinter import configparser import sys import logging import paramiko import os

Previous knowledge (familiarity)

I often think it's important to use something you are familiar with. There may be a better tool that does more and has more bells-and-whistles. However, it's important to stick with what you know, especially in a time sensitive situation. I could have easily learned a better language for application development. I'm sure there are better systems out there that are more efficient, require less code, consume less resources, etc. It was important for me to stick to my guns, Pythons. One of the requirements I self-imposed was a 3 week deadline. I felt 2 weeks was too fast and 4 weeks prolongs it and promotes procrastination. I wanted to avoid both situations; I felt that 3 weeks was a good medium. Being able to resort to Python, knowing that whatever I encounter Python has an answer.

Python also has an extremely large community. From what I have seen on Reddit and Stackoverflow, much more helpful too ;)

Resources Used

Hosting and Collaboration Tools

I will be utilizing AWS cloud services to help accomplish this project.

AWS EC2
AWS Cloud9

For code management and versioning I set up a Github private repository.

Getting Help

So I knew I couldn't accomplish this project on my own within the time frame I set. So I crowdsourced for help. Two other people are working on this project with me. I don't know them, but I have to give them proper credit because without their help this project would never have gotten done.

Python IDE (KISS)

The IDE I chose to work with is the Python IDE. I like to follow a simple philosophy - Keep It Simple Stupid (KISS). Keeping my working environment as bare bones as possible allows me to learn and understand what I am doing more, because I am at the wheel. It's like driving a manual compared to an automatic. Both are great and have their benefits, choose what fits you.

I remember being made fun of by my college professors in my Java 101 class for using JGRASP, jokes on them - I got a B.

Concept Design and Thoughts

The first design was based around the BeyondTrust stack. It was intended to just call an Ansible playbook based on the selections made.

This design would work really well for a single product deployment. The problem is that it doesn't follow any good dynamic design principles. It's extremely linear and doesn't allow for expandability.

The next design concept takes all of that BeyondTrust stuff and chucks it out the window. Instead of focusing on one product, why not allow the user to execute any playbook the way they wanted to using Linux syntax?

This is where I believe the final iteration of the product will end up. This design allows the product to be more dynamic and not locking it into a single use case.

Sharing Code

Creating an Ansible Hosts file based on system type and service. Note: this isn't final, but it provides a general understanding on how to create a more dynamic inventory based on the service you want to the target hosts.

Reminder

I want to remind everyone this project is still in progress. I am looking for help if anyone would like to contribute.