To monitor Tomcat with Munin 2.0 on Debian GNU/Linux (tested on Debian Squeeze with Tomcat6 and Debian Backports), you need the following steps.
First, you need to install package tomcat6-admin which enables the Tomcat Manager app we will be using.
# apt-get install tomcat6-admin
Next, create a user with a manager role in Tomcat, editing /etc/tomcat6/tomcat-users.xml and adding the following two lines in the appropriate list.
<user username=”munin” password=”Munin” roles=”manager”/>
Restart Tomcat to reread its configuration and enable the newly-installed Tomcat Manager app.
# service tomcat6 restart
Configure the Munin tomcat_* plugins adding a file /etc/munin/plugin-conf.d/tomcat with the following content:
Enable the tomcat_* plugins:
# cd /etc/munin/plugins/; ln -s /usr/share/munin/plugins/tomcat_* .
Restart Munin node:
# service munin-node restart
Why re-invent the wheel? This post gives ample details: http://www.cyberciti.biz/faq/find-linux-distribution-name-version-number/
The documentation to install BigBlueButton 0.64 on CentOS (and on most other distributions) is really excellent. However, I found that CentOS 5.5 had not been documented yet, so I tried it and run into a few problems. I explain below how to get it all sorted out. I installed CentOS5.5 from a DVD in “server” mode, so without graphical interface. Once installed, I proceeded with the following.
I followed the first directions from http://code.google.com/p/bigbluebutton/wiki/RPMPackaging#How_to_Install_BigBlueButton_on_CentOS_5.4
However, I ran into my first problem: the epel could not be found by the script, so I had to update the script to change epel-release-5-3.noarch.rpm for epel-release-5.4-noarch.rpm, then launch the script again.
Probably because the script had a problem, I had another problem later during the install: /etc/init.d/asterisk conflicted with asterisk14, so I had to remove Asterisk first: “yum remove asterisk14-core-1.4.36-1_centos5.x86-64”, then launch again “yum -y install bigbluebutton”
At this point, bigbluebutton should work fine from the local machine (if you are doing that on a CentOS5.5 server without graphical interface, try installing lynx and launching lynx localhost. If you see text saying BigBlueButton, you’re OK), but accessing this server from another machine might not work (could not connect, error 500, etc). This is (most probably) because your server has an iptables (default firewall) configuration preventing access on port 80 to your server from another computer. The quick solution to try it is to shut down iptables with “/etc/init.d/iptables stop” and try connecting again. If that works, then you’ll have to setup your firewall properly.
Finally, to install the desktop sharing utility, you will have to launch “yum install bbb-apps-deskshare”.
You might also be interested (as a backup- into a guide that explains how to install BigBlueButton on CentOS5.4 step by step: http://code.google.com/p/bigbluebutton/wiki/InstallingBigBlueButtonCentOS
BBB 0.70 seems to install fine on top of the 0.64, but the sound doesn’t work and the whiteboard features are not registering write operations (just showing on screen).
- Editar (como admin) el fichero /etc/vim/vimrc y encontrar la línea que dice “syntax on” o “syntax off”
- Asegurarse que esta línea está a “syntax on” y que no esté comentada (una doble comilla al inicio la comentaría)
- Editar cualquier fichero de código usando vim… Ya está
- También se puede configurar por cuenta, usando el fichero .vimrc en la carpeta del usuario mismo y poniéndole un “syntax on”
Esta funcionalidad no usa muchos recursos (mientras no esté editando ficheros de más de medio MB) y es muy útil para ver el código de forma más clara/ordenada.
BeezNest is the proud provider of the hardware and systems architecture running the main server for Mantis, the missing link between multi-species full genome comparisons and functional analysis.
In February 2008, Raphaël Helaers, main developer of Mantis, working at the Université Libre de Bruxelles, and fellow student in my computer sciences studies, asked us if we were interested in providing an affordable, ultra-resistant, architecture for the server of their multi-species genome comparison tool. At the time, Jérôme configured the server, as it is his specialty, and we provided a few hours of support to get it launched and managed by the development team.
Two years, a full delocalization of the server from Belgium to Switzerland and one hardware cleaning later (pieces moved during the expatriation), the server is still in excellent shape and Mantis just released version 1.1!
We are very happy of the success of this project, which is one of the leading scientific projects in the genome study area.
Incidentally, and although unrelated, Mantis is now hosted in the Geneva University, for which we happen to be the proud publishers of the e-learning system in use there: Chamilo!
Disclaimer: this article does not pretend to be a complete picture of using swap on UNIX.
Most of the time, recent GNU/Linux distributions insist on creating a swap area.
Swap is generally used to temporarily store memory used by running(/sleeping) applications, but might as well be used to store a copy of RAM to disk for hibernation. As disks are still many times slower than RAM, it always comes with huge performances impact.
Historically, RAM was so expensive that UNIX users bought only a fraction of actually used memory, and relied on swap for 2/3 of it (number still found in many advices today, while it is certainly outdated).
Today, you can buy quite a huge amount of RAM (even ECC) for almost nothing, it is not uncommon to be able to buy more than 4GB for less than 100€. So today, you buy RAM based on the total memory used by all the applications that might ever run at the same time. Of course, you probably don’t need then to allocate three times that amount to swap, especially when you know applications won’t use it.
The main danger of allocating much swap is that some application goes mad, eats up all memory, then swap and starts slowing down the whole machine (because it brings I/O in the dance), then (and only then) eventually get killed by the Linux OOM Killer, which is rather basic (just kills the running application taking currently the more memory, so might even miss the real guilty). Without swap (or reasonable amount), in contrast, the kill would happen far earlier, and not generate incredible I/O usage levels.
Of course, I/O impact is even worst in virtualized environments.
GNU/Linux supports swapping to a file on any filesystem, with reasonable performance impact since kernel 2.4. This might be useful whenever needing a temporary increase in available memory, I’m writing this article with that goal in mind.
Create a zero-filled regular file (following example would create a 1024x1M=1G swap size):
dd if=/dev/zero of=/.swapfile bs=1024 count=1M
Setup a swap area in it:
Activate swap to this file (would not survive a reboot):
To check it did it:
Disable swap to this file:
Of course, the file is not deleted on reboot, and you might reuse it several times.