I often work with virtual Debian instances to test new stuff. In order to reduce the likelihood that another test I’ve run before interferes with the new test, I clone them. I’ve installed a base system which runs using VirtualBox. Whenever I want to test something new I just clone it with this neat little function:
Unfortunately there’s one little change you have to make…
You might have seen my previous article about creating executables without dependencies http://www.codeblog.ch/2011/06/statically-linked-linux-executables/. While I still try to focus on Oracle and concrete5, there’s often a situation where I have to build a small, portable and fast tool. I didn’t look at something specific, I rather tried several solutions and now it’s time to add another language to this list.
Google created Go a while ago and released version 1.0 at the end of March 2012. Some might wonder why Google created yet another new language. You can find the official answer here: http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the_project. To me the most important things worth mentioning are:
- Fully garbage-collected
- Support for concurrent execution and communication
- Doesn’t need a virtual machine like JRE
- Construction of system software on multicore machines
This doesn’t mean that Go is restricted to those things, you does a lot more but when comparing it to Java and other languages, these are a few major points of interest. I’ve run my experiment on a freshly installed Debian 6.0 operating system. My favourite distribution as it’s small and efficient, I can’t give you instructions for Fedora and other system but if you’re familiar with some of the basic libraries for your distribution, it shouldn’t be too difficult to get Go up and running.
- 5 comentarios
If you’re a *unix admin you probably like SSH a lot. Even if you have to work on a Windows computer you can simply download a small tool like Putty and you’re ready to work on your server. However, there are situations where not even Putty works – if you’re behind a firewall that filters the outgoing traffic as well. It usually makes sense to block outgoing SSH traffic in a big company because you could easily create an encrypted tunnel to move secret data to any server you want.
But there’s another way to access your server using SSH like tools without having to worry about encrypted tunnels or any other threats SSH could cause. It’s called shellinabox and can be found on Google Code.
If you’re working with debian like I do, you can even download a prebuilt deb file.
dpkg -i shellinabox_2.10-1_i386.deb
The installer creates an init script located in /etc/init.d/shellinabox. As soon as it has been started you can access your shell using any webbrowser using an address like this: https://localhost:4200. But the port 4200 is usually not accessible if you’re working behind a firewall that blocks SSH traffic. Let’s use apache to redirect traffic from HTTPS to 4200. We have to enable mod_proxy if it’s not already active:
ln -s ../mods-available/proxy.conf
ln -s ../mods-available/proxy.load
ln -s ../mods-available/proxy_http.load
Edit the site file where you want to add your shell, I used /etc/apache2/sites-available/default-ssl and added these lines:
Allow from all
Shellinabox uses https by default as well and is accessible by any ip address. We want to change that, let’s edit this file /etc/init.d/shellinabox and add SHELLINABOX_ARGS (the last line in the following box):
# Set some default values
If you now restart all the services “/etc/init.d/shellinabox restart” and /etc/init.d/apache2 restart”, you’re shell can be accessed by https://localhost/shell from anywhere you want!