Straight from VirtualBox website.

As some may know, part of my duties is working with a custom distro and performing many “low level” changes to the operating system to make things work… let’s say, not as they are supposed to.

VirtualBox has been my virtualization platform ever since Linux as my primary Operating System. I say primary because, for testing purposes, Windows is still a big part of my life, Visual Studio, and so on.

VirtualBox continues to step up its game, at times a step behind VMWare, but hey, they have $$ some fair advantage.

As I love OpenSuse here you have VirtualBox in Windows running OpenSuse.

But some let’s list the new awesome features:

1. Paravirtualization Support for Windows and Linux Guests: Significantly improves guest OS performance by leveraging built-in virtualization support on operating systems such as Oracle Linux 7 and Microsoft Windows 7 and newer.
2. Improved CPU Utilization: Exposes a broader set of CPU instructions to the guest OS, enabling applications to make use of the latest hardware instruction sets for maximum performance.
3. Support of USB 3.0 Devices: Guest operating systems can directly recognize USB 3.0 devices and operate at full 3.0 speeds. The guest OS can be configured to support USB 1.1, 2.0, and 3.0.
4. Bi-Directional Drag and Drop Support for Windows: On all host platforms, Windows, Linux, and Oracle Solaris guests now support “drag and drop” of content between the host and the guest. The drag and drop feature transparently allows the copying or opening of files, directories, and more.
5. Disk Image Encryption: Data can be encrypted on virtual hard disk images transparently during runtime, using the industry-standard AES algorithm with up to 256-bit data encryption keys (DEK). This helps ensure data is secure and encrypted at all times, whether the VM is sitting unused on a developer’s machine or server, or actively in use.

As you know, in Takelan, we use VirtualBox, a LOT, and we use it even for critical mission applications as PfSense running some of our perimeter Firewalls. “www.pfsense.org/” One thing we can’t complain about is Performance.

VirtualBox in this new delivery has made a HUGE step forward in virtualizing technology and just for the fun of it. Here I am, typing this post straight from my Windows VM in OpenSuse.

Why don’t I do it the other way around? and Virtualize OpenSuse?

Because of HTOP! nah, seriously, because Linux just makes my life easier.

And if you don’t get to see the coolness in there.. then, you’re not a real SysAdmin lol.

And with that… all I can say is, Happy Sysadmin’s day everyone.

Abstract:

The problem of managing multiple servers that do basically similar stuff and are used to host in house applications. Avoiding configuration time hogs, and automation of server configuration allowing fast deployments with no scaling limit.

The problem:

The problem with MultiAll is the fact of having all the servers on sync when they are in different “Farms or Grids” and the fact that one server can provide services to more than one porpuse. This is why we invent the “Pool system” where all the servers respond or act for a defined pool.

If a server responds to multiple pools the aggregation of every pool is the server.

Understanding how we can make it work:

Under our research its possible to merge more than one server to work for a common goal, doing some modifications to the normal database driven apps to have a cache table, and when that server is unable to communicate to others under the same pool they save the changes they have to make to their brother servers and later on when they are back online deploy the changes.

On the file system side, every server is responsible of keeping others from the same pool up to date, bi partitioning the problem as every server is responsible for others and their self.  We’re doing similar to how Rsync works, and we would only push differences between servers under a secure connection IE: (VPN).

By this moment we would have a DB Layer abstraction for multiple servers responding to a DB and file system.

Next is the Domain Name Server problem, that we don’t want clients reaching servers that are offline due to maintenance or problems, for this we’re developing on BIND 9 an abstraction layer that every server in a pool must be “Network Aware” of others of his kind, and if hes unable to reach others, then he must change the DNS registry to reflect the changes.

How MultiAll solves the problem:

Basically MultiAll will work as a service provider inside the server, as a global abstraction layer, and once the application is provided with a bridge or connection layer to it, it would be able to take advantage of the system. MultiAll has as key features:

1. Topology-Aware Neighboring System (TNS): provides a topology discovery service for the servers (or “nodes”), which may eventually “recalculate” the topology in case of unexpected downtime (such as network, power or hardware failures, among others) or in cases of planned downtime (such as server maintenance, hardware upgrades or migrations). The different synchronization agents of the “Multi All” depends on information learned through TNS, therefore it is considered a critical component of the “Multi All” system.
2. System Baseline Monitor (SBM, formerly known as “checker”): provides a 24/7 server health monitoring, locally on each server (or “node”) using “Baseline Rules”. These rules are defined on a “per pool” or “per server” basis, allowing the configuration to be as granular as needed, making exceptions if the need arises. The health status is published via TNS using standardized codes known as “SBM Statuses”. It is also considered a critical component of the “Multi All” system.
3. File System Synchronization Agent (FS-SA): lets you define structures inside your filesystem to keep synchronized across a pool of servers. FS-SA, used in combination with the rest of the “Multi All’s” Synchronization Agents (SA’s) provides you with high availability, data redundancy and server load balancing on your pool of servers.
4. Software and Libraries Synchronization Agent (SL-SA): especially useful for large-scale unattended deployments, the SL-SA keeps all your software packages, services and libraries consistent across the pool, raising awareness to the system administrators when possible conflicts, incompatibilities or other issues arise.
5. Database Synchronization Agent (DB-SA): keeps the different database servers of the pool synchronized. Depending on the needs of the underlying applications, the DB-SA may either work 24/7 to keep the DBs in perfect sync, or you could define your own database synchronization policies.
6. Domain Name System Synchronization Agent (DNS-SA): keeps the DNS zones up to date with the pool’s topology either via a pull-push synchronization mechanism (handled by the FS-SA) or by rebuilding the DNS zone according to the topology discovered by the TNS.

The project has gotten a bit more ambitious… so here is how its changed!

Okay so some research has been going on, and the project has been growing quite a bit. Among the changes that have been happening around, it has gotten bigger, now all the things stated before, are part of a much larger system now.
TakeConnector will now be the daemon that will keep our infrastructure.

Overview: After having a high temperature in one of our servers and not being able to notice it as a ‘heat wave’ came in… I thought about adding to our monitoring stack a simple script to monitor the temperature and notify us in case something goes wrong.

Basically, the script will run SENSORS and parse the output from it to let us know if something goes wrong, and leave a simple logline to check the average temperatures.

So packages you’ll need : sensors.

To install install sensors and be able to run this script:

1. Install the lm-sensors package.
2. Run sudo sensors-detect and choose YES to all YES/no questions.
3. At the end of sensors-detect, a list of modules that needs to be loaded will displayed. Type “yes” to have sensors-detect insert those modules into /etc/modules, or edit /etc/modules yourself.
4. Next, run sudo service module-init-tools restart This will read the changes you made to /etc/modules in step 3, and insert the new modules into the kernel.
5. Copy this script to ~ (root folder), add permissions to execute chmod u+x (scriptname).sh
6. crontab -e add the line “@reboot /root/(scriptname).sh

#!/bin/bash
######################################################################################
# Derek Demuro, this script is given as is, CopyLEFT                                 #
######################################################################################
######################################################################################
# README                              LEAME                                          #
######################################################################################
# This script will run and check the temperature, in case of being high, MAIL!
#
############################To Set Up#################################################
#
# To set this script up, you'll need to add it to a cronjob to run on boot
# Most linux distros will allow a param @reboot /(path)/servermon.sh
# So... crontab -e
# At the bottom add: @reboot /(path)/servermon.sh
# REMEMBER TO ADD EXECUTABLE BIT TO THE FILE (777 Permissions)
######################################################################################
# SCRIPT CONFIGURATION                                                               #
######################################################################################
### Where should the log be saved?
readonly LOGNAME='servertemp.log'
### Who should we mail on error
readonly MAILTO='<a href="mailto:mail@derekdemuro.me" class="mailto">mail@derekdemuro.me<span class="mailto"><span class="element-invisible"> (link sends e-mail)</span></span></a>'
### How much time between check's?
readonly SLEEPTIME=30
###Alert if temp Above
readonly MAXTEMP=75
###ServName
readonly SERVNAME='UYMF1DEB'
##How long to sleep after message sent
readonly SLEEPERROR=216000
### How many records to keep
readonly CLEARLOGTMS=1000
######################################################################################
#################################FUNCTIONS START################################
 
###Function to clear the log
function clearLog() {
  echo 'Log cleared' > $LOGNAME
  echo 'Script will run ' $1 ' times then will clear itself'>> $LOGNAME
  return 0
}
 
#################################FUNCTIONS FINISH################################
#################################MAIN SCRIPT FUNC################################
while [ TRUE ]; do
    #add 1 to times
    times=`expr $times + 1`
    ##CLEAR THE LOG
    if [ $times -eq $CLEARLOGTMS ]; then
        clearlog
        $times=0
    fi
    ##Run script for every line in serverList
    currentTemp=`sensors|grep Core|awk '{print $3}'|cut -b2,3,3|tail -1`
    if [ $currentTemp -gt  $MAXTEMP ]; then
        echo -e "\e[00;31m`date +'%Y-%m-%d %H:%M:%S'` ALERT: Current temperature: $currentTemp, at server: $SERVNAME \e[39m"
        mail -s "ALERT: Temperature above umbral" $MAILTO -a "Reply-To: " <<< "`date +'%Y-%m-%d %H:%M:%S'` ALERT: Current temperature: $currentTemp, at server: $SERVNAME"
        sleep $SLEEPERROR
    else
        echo -e "\033[38;5;148m `date +'%Y-%m-%d %H:%M:%S'` All good: $currentTemp at server: $SERVNAME \033[39m"
    fi
  ##We sleep till new run
  sleep $SLEEPTIME
done

So there you have the script, now if you want a list of DNS’s to check your domains against…

8.8.8.8
8.8.4.4
156.154.70.1
156.154.71.1
208.67.222.222
208.67.220.220
198.153.192.1
198.153.194.1
4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
4.2.2.5
4.2.2.6
67.138.54.100
207.225.209.66
85.88.19.10
85.88.19.11
87.118.100.175
94.75.228.28
62.141.58.13
85.25.251.254
85.214.73.63
212.82.225.7
212.82.226.212
213.73.91.35
58.6.115.42
58.6.115.43
119.31.230.42
200.252.98.162
217.79.186.148
82.229.244.191
216.87.84.211
66.244.95.20
204.152.184.76
194.150.168.168
80.237.196.2
194.95.202.198
88.198.130.211
78.46.89.147
129.206.100.126
79.99.234.56
208.67.220.220
208.67.222.222
156.154.70.22
156.154.71.22
85.25.149.144
87.106.37.196
8.8.8.8
8.8.4.4
88.198.24.111
58.6.115.42
202.83.95.227
119.31.230.42
217.79.186.148
178.63.26.173
178.63.26.174
27.110.120.30
89.16.173.11
210.80.60.1
210.80.60.2
199.166.24.253
199.166.27.253
199.166.28.10
199.166.29.3
199.166.31.3
195.117.6.25
204.57.55.100
4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
4.2.2.5
4.2.2.6
64.129.67.101
64.129.67.102
64.129.67.103
151.197.0.38
151.197.0.39
151.202.0.84
151.202.0.85
151.202.0.85
151.203.0.84
151.203.0.85
199.45.32.37
199.45.32.38
199.45.32.40
199.45.32.43
192.76.85.133
206.124.64.1
67.138.54.100
220.233.167.31
199.166.31.3
66.93.87.2
216.231.41.2
216.254.95.2
64.81.45.2
64.81.111.2
64.81.127.2
64.81.79.2
64.81.159.2
66.92.64.2
66.92.224.2
66.92.159.2
64.81.79.2
64.81.159.2
64.81.127.2
64.81.45.2
216.27.175.2
66.92.159.2
66.93.87.2
199.2.252.10
204.97.212.10
204.117.214.10
64.102.255.44
128.107.241.185

Abstract:

The problem of managing multiple servers that do similar stuff and are used to host in house applications. Avoiding configuration time hogs and automation of server configuration, allowing fast deployments with no scaling limit.

The problem:

The problem with MultiAll is having all the servers on sync when they are indifferent “Farms or Grids” and the fact that one server can provide services to more than one purpose. This is why we invent the “Pool system” where all the servers respond or act for a defined pool.

If a server responds to multiple pools the aggregation of every pool is the server.

Understanding how we can make it work:

It’s possible to merge more than one server to work for a common goal under our research, making some modifications to the typical database-driven apps to have a cache table. When that server is unable to communicate to others under the same pool, they save the changes they have to make to their brother servers, and later on, when they are back online, deploy the changes.

On the file system side, every server is responsible for keeping others from the same pool up to date, bi partitioning the problem as every server is responsible for others and themselves.  We’re doing similar to how Rsync works, and we would only push differences between servers under a secure connection IE: (VPN).

By this moment we would have a DB Layer abstraction for multiple servers responding to a DB and file system.

Next is the Domain Name Server problem. We don’t want clients to reach servers offline due to maintenance or issues; for this, we’re developing on BIND 9 an abstraction layer that every server in a pool must be “Network-Aware” of others of his kind. If he’s unable to reach others, he must change the DNS registry to reflect the changes.

How MultiAll solves the problem:

MultiAll will work as a service provider inside the server, as a global abstraction layer. Once the application is provided with a bridge or connection layer to it, it would take advantage of the system. MultiAll has as key features:

1. Topology-Aware Neighboring System (TNS): provides a topology discovery service for the servers (or “nodes”), which may eventually “recalculate” the topology in case of unexpected downtime (such as network, power or hardware failures, among others) or instances of planned downtime (such as server maintenance, hardware upgrades or migrations). The different synchronization agents of the “Multi All” depend on information learned through TNS; therefore, it is considered a critical component of the “Multi All” system.
2. System Baseline Monitor (SBM, formerly known as “checker”): provides a 24/7 server health monitoring, locally on each server (or “node”) using “Baseline Rules.” These rules are defined on a “per pool” or “per server” basis, allowing the configuration to be as granular as needed, making exceptions if the need arises. The health status is published via TNS using standardized codes known as “SBM Statuses.” It is also considered a critical component of the “Multi All” system.
3. File System Synchronization Agent (FS-SA): lets you define structures inside your filesystem to keep synchronized across a pool of servers. FS-SA, used in combination with the rest of the “Multi All’s” Synchronization Agents (SA’s), provides you with high availability, data redundancy, and server load balancing on your pool of servers.
4. Software and Libraries Synchronization Agent (SL-SA): especially useful for large-scale unattended deployments, the SL-SA keeps all your software packages, services, and libraries consistent across the pool, raising awareness to the system administrators when possible conflicts, incompatibilities or other issues arise.
5. Database Synchronization Agent (DB-SA): keeps the different database servers of the pool synchronized. Depending on the needs of the underlying applications, the DB-SA may keep the DBs in perfect sync, or you could define your database synchronization policies.
6. Domain Name System Synchronization Agent (DNS-SA): keeps the DNS zones up to date with the pool’s topology either via a pull-push synchronization mechanism (handled by the FS-SA) or by rebuilding the DNS zone according to the topology discovered by the TNS.

The project has gotten a bit more ambitious… so here is how its changed!

Okay, so some research has been going on, and the project has been growing quite a bit. Among the changes that have been happening around, it has gotten bigger, now all the things stated before, are part of a much larger system.
TakeConnector will now be the daemon that will keep our infrastructure.

Abstract:

Using automation processes and technical skills, the idea is to develop a modularized, configurable, and environment aware trading system that can adapt to different currencies, news, and market trends without or with little human interaction.

The problem:

Automated trading is the same as manual trading, leaving the feelings out of the equation. Followed by intuition, computers don’t have feelings or intuition; that is the whole idea’s biggest downside. So, to begin with, we must break the problem into pieces, thinking about the best way to get accurate signals from the market, running them by our own “automated market entry proofing,” avoiding wrong signals and leaving only the safe ones.

Understanding how we can make it work:

Using our technical skills in math, programming, and tests, we can produce a system aware of news, wrong long and short market entries. Taking advantage of those brokers who widen the spread during news time, avoiding entering the market on those moments.

We are using trading strategies as BEP (Break-Even Point), which will allow us to step back on our initial entry or lot size. And according to the trades, we have opened running them through the system, deciding if the stop loss and take profits are well fitted and if the sudden market change happened being able to step away without losses.

As you may or may not know, in Forex, you always lose. Every time you win, someone else is losing. Vice versa, so we have to try to do a great job on money management, and later on, trying to show or teach the computer the best well-known methods to step in or out of market-defining possible conditions, or giving the system a way to understand either good or bad moments.

How this expert solves the problem:

We are making this expert with all the knowledge we have on Forex, plus technical and mathematical skills.  

Dividing the problem on the following steps:

1. Shutdown (System that will make the expert stop trading and once all trades are close, shutdown completely)
2. Emergency Shut Down (Close everything assuming losses).
3. Money Management (According to how much money you’re investing, calculating your risk choose the best lot sizes).
4. Lot Adjustment: Adjust lots manually if you change from one broker or another or don’t want money management.
5. Entry Signals (Configure the way according to the pair to be traded what signals work best or are more accurate).
6. Exit Trades: (Configure how opened trades will or should exit, setting stop losses, take profits, monitoring, etc.)
7. Trade Monitor: (Configure what will be monitored from opened trades).
8. Display: (Configure what is displayed on the screen when on automated trading).
9. Alerts: (Configure when a trader should be alerted).