Snap! Websites
An Open Source CMS System in C++
When I first start of Snap!, I had one project, the snapwebsites folder.
As I started growing the project, I wanted to have some features that required other modules such as the log4cplus library to handle logging.
The fact is that as a result the library (read: common code to all the Snap! Website services) as grown to be a really large one! Difficult to manage and each time a small change is made, we incur a long wait for rebuilding everything.
So we started working on breaking up the library in smaller parts. We already have some functional projects which now encompass some of the low ...
Originally, this project was a break up of the log.cpp and log.h from the libsnapwebsites to its own project. However, that implementation had a dependency on log4cplus which has all sorts of drawbacks for our Snap! environment. Don't get me wrong, up to here, it served us well and log4cplus version 1.2.x works very well.
That being said, our way of handling configuration files, the fact that we like to use fork() and a few other things, made us think that having our own implementation of a logger would improve our general environment quite a bit. This newer version of the logger is the result.
Today I was checking my logs and noticed this entry. As we can see, within about 600ms, an attacker was trying to connect to many different ports (20480, 20736, 36895, 37151, 22528, 16671, 14340, 20992, 4135, 64288, 45090, 21248, 21504, 31775, 39455, 42254, 47115.)
Note: I hid the destination URL (x.x.x.x) on purpose. However, I did not hide the source!
Jul 23 11:20:34 finball1 kernel: [1661019.650298] [iptables] unknown: IN=eth0 OUT= SRC=87.62.140.210 DST=x.x.x.x LEN=44 TOS=0x00 PREC=0x00 TTL=57 ID=52074 PROTO=TCP SPT=26091 DPT=20480 WINDOW=131 RES=0x00 SYN URGP=0 Jul 23 11:20:34 ...
Today I wanted to get a plugin to work against the snapmanager.cgi executable's server.
The idea is pretty simple, the process loads the plugins and one of them (so far) wants to connect against the generate_content() signal, only that signal is part of the manager_cgi class which is not part of a .so library. Because of that, it doesn't expose its functions by default.
This is a quite interesting problem because it makes sense that the executable functions would not be visible to the dynamic linker. It should not be required. Actually, this is the first time I need such a feature, ...
Today I started work to switch from using log4cplus with files directly to using the loggingserver. Not only that, it is using the newest version (on the edge!) which is 1.2.0-rc3. Up to here, no major problem.
However, the newer version forces you to use a version of the log4cplus library which is multi-threaded. This causes a major problem because the server makes use of fork() to create child processes each time a connection is made. There are several reason to do so, but there are a couple that I think are certainly the most important ones:
Just made a new addition to the project: snapwatchdog.
This is a daemon running in the background used to gather statistics about each server running in a Snap! cluster.
The statistics are saved in an XML file1 and already include the following information:
Snap! Websites
An Open Source CMS System in C++
