tsocks provides transparent network access through a SOCKS proxy. This is common in firewalled LAN environments where all connections to the internet need to pass through a SOCKS server on the firewall. tsocks intercepts the calls applications make to create tcp connections and determines if they can be directly accessed or need the SOCKS server. If they need the SOCKS server their connection is negotiated with the server transparently to the application. This allows existing applications to use SOCKS without recompilation or modification. tsocks is a wrapper library for a number of socket networking functions. Essentially it’s the equivalent of the socksified winsock.dll libraries that are available for Windows.
I have just finished working on the first public version of the set of simplified vintage looking user interface elements for *NIX shell.
It is a simple shell script full of ANSI ESC-sequences to generate frames, windows, buttons and etc. Though, there is a lot of things to be implemented and fixed (as it’s an early development stage), I have no patience to hide it from public any more. So beware of bugs if you decide to try.
Download repository from GitLab: amen.sh, post me bug reports.
Shortly after I finished developing the BeaST storage system concept and ended testing it in the virtual environment I faced a problem of how to find a two-headed bare-metal server with a bunch of shared drives.
In fact I did not hope to find a platform for this actually quite expensive testing, but I was lucky enough to get a fantastic offer from the Open Analytics guys to take part in their project of testing the BeaST as an open-source reliable storage system for their needs.
One sunny morning Tobias Verbeke, Open Analytics Managing Director, contacted me and showed an amazing equipment specification, that fits the BeaST testing very well.
Should I say, I agreed immediately? Together with Ronald Bister, who assisted me from the Open Analytics side, we installed FreeBSD and configured the BeaST storage system as well as the client for testing.
As the three SSD drives were not used in that configuration the only tricky thing was to balance all the 24 SAS drives across controllers and not to mix them all together: I had to enable the multipathing for each physical drive as well as to create mirrored and then striped RAID-groups.
Luckily my old GEOM configuration parsing script allowed me to find all the volumes and helped to prepare the right configuration (a bit later I updated it to show SAS-addresses – sas2da.sh and even add location of each drive in the enclosure – sas2da_mpr.sh)
The BeaST Classic – dual-controller storage system with ZFS and CTL HA configuration was obviously more complex to configure. It took more time to implement everything properly and enable the smooth failover and failback operations. We have finally achieved the stable Active-Active state of the testing system (though for the sake of preventing potential issues on the working system the engineers of Open Analytics decided to use the Active/Hot-Standby mode on the backend-pools) and left the BeaST system to work as the storage system for testing environments at Open Analytics.
So, what do we have at the end of the story?
We have tested the BeaST storage system on the real hardware in both RAID and ZFS configurations. I’m absolutely happy the BeaST performs well and the Failover/Failback operations work normally in both the Active/Active and the Active/Hot-Standby modes. Yet, I have a lot of work to do:
improve the BeaST Quorum/arbitration subsystem to handle properly all possible hardware failures
Yes, it’s me who spends long winter holidays playing with children’s toys. We bought a wonderful LEGO BOOST creative toolbox for my son, but I insidiously picked it from the child and started enhancing it with Python to add Voice Control to order the robot simple movement commands. Sometimes it obeys my Russian English, but not always 😉
And “yes”, no Internet connection is required for the Vernie voice control to work 😉
Sources and installation instructions are on Gitlab. Feel free to message me on any issues.
The year is almost near the end and I’m feeling Christmas in the air already, now it’s time to recall what was done and count some results.
So, the first half of the year I used GitHub as a platform to store my code and manage updates.
As you see, I didn’t do many commits every day. That’s because I’m too lazy I still prefer developing old-school ways (yes, blame me for that 🙂 ) and keep all changes on my PC, pushing only valuable changes to public repositories. Also, I mostly code in my free time: in the evenings and on vacations, therefore you can see empty gaps between commits.
The other reason is that my favourite the BeaST project has a main page only on my blog and the BeaST Quorum (BQ) source code on SourceForge platform.
In June I migrated most part of my code to GitLab, though I didn’t also delete the GitHub account for references and history.
So, what projects can I mark “successful” this year? Actually, I’m looking sceptically at all of them, but at least I feel less shame mentioning these projects, code and activities:
The BeaST storage system at Open Analytics – a consulting company specialised in supporting the data analysis process of its customers end to end. Together, we have launched tests of the BeaST on a real bare-metal hardware. And it works! After functional tests the BeaST is going to be a LUNs provider for the Kubernetes cluster of the Open Analytics testing environment. I promise to write a post (or two) about this significant milestone in the life of the BeaST project.
svcstats – a CLI stat-like utility for reporting IBM SVC/Storwize storage system performance statistics using SMI-S interface. Though I started coding it in 2017, a lot of work has also been done this year.
sp_ping – my own simple ICMP ping implementations in Python. It supports both IPv4 and IPv6 protocols as well as unicast/broadcast/multicast requests. It’s code I later reused in the Net Radar – Simple IP networks browser software, which is currently in the early development stage.
ds8k_perfs.py – Another stat-like utility. It displays Open-systems performance metrics for IBM DS8000 storage system in CLI. Utilises SMI-S protocols as well.
supermatic – a simple HTTP server I wrote just for fun as Bourne Shell script. Yes, It’s a toy, but who cares? 🙂