Back in the days when I mostly did routing stuff I spent the whole day configuring SROS devices via SSH. And once in a while I saw that SSH session or its server part (or even underlying connection) glitched, resulting in a corrupted lines feeded to the device.
What was also quite common is to make a mistake (i.e. syntax one) in a single line and watch like the rest of config got applied to the wrong context.
These sad facts pushed me to create a rootifier CLI script, that was converting tree-like SROS config into flattented (aka rooted) fashion.
Now I decided to make a web service of that script, that is publicly available at https://rootifier.netdevops.me/
Flask documentation is very clear on where is the place for its built-in WSGI application server:
While lightweight and easy to use, Flask’s built-in server is not suitable for production as it doesn’t scale well and by default serves only one request at a time.
So how about I share with you a Dockerfile that will enable your Flask application to run properly and ready for production-like deployments? As a bonus, I will share my findings discovered along the way of building this container image.
Today I faced a task which required first to establish an SSH tunnel in a background process and later use this tunnel for SSH connection. What seemed like a child’s play first actually had some fun inside.
A problem were hidden right between the moment you spawned
ssh process in the background and the next moment you tried to use this tunnel. In other words, it takes literally no time to spawn a process in the background, but without checking that tunnel is ready, you will quite likely receive an error, since your next instructions will be executed immediately after.
Consequently, I needed a way to ensure that the SSH service is ready before I try to consume it.
At work I always prefer KVM hosts for reasons such as flexible, free and GUI-less. Yet I never bothered to go deeper into the networking features of Libvirt, so I only connect VMs to the host networks via Linux Bridges or OvS. Far far away from fancy virtual libvirt networks.
Even with this simple networking approach I recently faced a tedious task of reconnecting VMs to different bridges on-the-fly.
My use case came from a need to connect a single traffic generator VM to the different access ports of virtual CPEs. Essentially this meant that I need to reconnect my traffic generator interfaces to different bridges back and forth:
Apparently there is no such
virsh command that will allow you to change bridge attachments for networking devices, so a bit of bash-ing came just handy.
xrdp is defacto the default RDP server for Linux systems sharing with VNC the remote access solution olympus. I personally found it more resource friendly and feature rich compared to VNC solutions I tried.
The only problem I found with
xrdp is that current Ubuntu LTS release Xenial 16.04 has a way outdated 0.6.1-2 version of xrdp in the packages repo. This version has no shared clipboard support, which makes remote support/remote access a tedious task.
Well, no need to compile
xrdp from sources (unless you want to), because you can leverage a ppa from hermlnx that has
xrdp 0.9.1-7 already built for amd64 and i386 systems
# all you need is sudo add-apt-repository ppa:hermlnx/xrdp sudo apt-get update sudo apt-get install xrdp
You can also try a
deb package of
xrdp 0.9.2 – https://github.com/suminona/xrdp-ru-audio
While Amazon Linux AMI has
yum as a package manager, it is not that all compatible with any RHEL or CentOS distributive. A lot of changes that AWS team brought into this image made it a separate distro, so no eyebrows should be given when battle-tested procedure to install python3 will fail on Amazon Linux. (Yeah, python3 does not come included yet in Amazon Linux)