For a while I have been using mRemoteNG purely as a SSH and Remote Desktop , but I was using Command Prompt, MinGW, and Cygwin as all outside programs. I wanted to integrate them in with mRemoteNG so I’d have just one window, and multiple tabs for my terminal programs. I’ll run through what I did to prepare and then set up the terminals in mRemoteNG.
- Choose your terminal: MinGW, Cygwin, GitBash, PowerShell, Command Prompt
- If using command prompt, you’ll have to also set it up in Console2. I haven’t had much luck with ConEmu.
- Make sure you download and install the latest versions, as they will come with the required software.
- Then determine if mintty is installed for your desired terminal, except Command Prompt and PowerShell as stated above.
- Download and install the latest version of mRemoteNG from the mRemoteNG website.
- Open the External Tools in mRemoteNG
- Add a new External Tool
- Locate the location of the mintty or Console2 program in relation to your desired terminal.
- Add your arguments
- For mine, I always start /bin/bash –login -i so I don’t get the standard /bin/sh
- Open the Connections panel
- Create a new connection and label it your desired terminal
- In the protocol row, change the protocol from RDP to Ext. App
- Choose your External Tool, and save it.
Now you should be able to double click on the connection and open a terminal inside of your mRemoteNG session. I also changed a few other options to put it under its own tab called Consoles. After making changes in the External Tools panel, however, you’ll have to restart mRemoteNG because for some reason it’ll either freeze, or crash for me.
mRemoteNG is written in VB.net and is available on GitHub to contribute content, or look at the code. There are a few shoot offs, one being in C#. The developer is sticking with VB.net though.
I was on the hunt for a very simple HA daemon, and stumbled across this. It seems to be working just fine, but I’m not sure if I’m doing it correctly. I’m brushing up on my C++ in order to read the code, and understand how its working so I can better refine my service scripts, and start/stop/monitor the services to be HA’ed. Visit the website for FreeHA: http://www.bolthole.com/freeha/.There is a lot of good documentation there, and I wanted to share my steps as well. The developer has put the code on the WWW GitHub for public view, and possible additions. Check it out at: https://github.com/bolthole/freeha
- =>Download the software freeha-1.0.tar.gz:
- $ wget http://www.bolthole.com/freeha/freeha-1.0.tar.gz
- =>Extract the Source files:
- $ tar -xvf freeha-1.0.tar.gz
- =>Decide on network interface configurations
- I used virtual interfaces and assigned 2 per NIC, and made the subnets 255.255.255.252 and the IP’s set to 192.168.x.x within those subnets. Since the FreeHA daemon says it requires two additional network interfaces and they cannot be on the same network, I went that route.
- =>Edit the Makefile for your specific OS flavor. I had to comment out the Solaris LDFLAGS and uncomment the Linux flags.
- Save the file, and return to the project directory. Make and Install the program
- $ make; make install
- This moves all the files into /opt/freeha/bin/ and /opt/freeha/bin/service_scripts
- =>Edit the startdemon to include correct IP’s
- ==>See startdemon – which is the example init script, to be placed in ‘/etc/init.d/’ on RHEL/CentOS systems.
- I edited the startdemon file to include the virtual NIC’s IP addresses and their small /30 network. The startdemon file is a basic “init” script, so one could use the same startdemon file and modify it, or write their own, and start it up how they want, and kill it how they want.
- Write the init script to start the freehad program from /opt/freeha/bin/ with the options to include the network addresses. This is typically only used for 2 nodes in a cluster, but if three or more are going to be used, there are certain switches that are required. For now, we’re only using two nodes, so we have two private interfaces for the nodes to communicate. Include those into your init script, or just rename the startdemon script to your init script.
- Once the daemon starts, the init script should not include the starthasrv script, it will listen on the specified interfaces and once it connects with another freeha daemon, those two daemons will negotiate who is the master, and then the master will start up the services using the starthasrv script.
- =>Edit the starthasrv to include the startup scripts
- ==>See starthasrv
- Write the starthasrv to simply call the *.start scripts from /opt/freeha/bin/service_scripts/. The developer says that the .start/stop/monitor scripts should be written to take in input. I suppose this is to help to cut down on editing multiple files and just edit the start/stopmonitorhasrv scripts. When editing the starthasrv script, be sure to have it call the .start, then check to make sure that script executed cleanly, looking for a 0, if not, fail, and print an error stating what failed.
- =>Edit the stophasrv to include stop scripts
- ==>See stophasrv
- stophasrv does just what it says too, it stops the services to be HA’ed. I did it in reverse order from the starthasrv basically. It’ll close the network interface, then it’ll kill the zabbix_server processes.
- =>Edit the monitorhasrv to include monitor scripts
- ==>See monitorhasrv
- The monitorhasrv script should check to make sure the processes are working on the local system. If they are not working, then it should send an alerthasrv message and fail over. If the monitor has failed, FreeHAd should call stophasrv and kill all the services listed, and then the slave node should pick up the responsibility.
- =>Create Startup scripts for desired processes
- ==>See zabbix-server.start
- ===>zabbix-server.start simply brings up the zabbix-server daemon itself. In the spirit of the program, a commandline argument is passed to this, so I just included the init script, /etc/init.d/zabbix-server, and inside the script I just did ‘$1 start’.
- ==>See vip.start
- ===>vip.start simply brings up the virtual interface, then assigns the VIP to the interface.
- Monitor your FreeHAd
- =>See monitorFreeHAd
- For the FreeHAd status of the nodes in the cluster, use the command suggested from the website, ‘while true ; do clear ; date; cat /var/run/freehad ; sleep 1 ; done’
- =>See monitorSyslog
- On CentOS 6.4, there is no real syslog anymore, those logs are directed to /var/log/messages. Just use a ‘tail -n10 -f /var/log/messages’.
To run all of this, I might need to add in a ‘nohup’ into my init script so that the user doesn’t have to stay logged in all the time. I also used ‘screen’ to run all of this at the same time so I could quickly see everything that was going on.