PacketPro 1.7.0
Posted on Tuesday, 15th January, 2008 in Life
After blogging the last time about the PacketPro 450 LoadBalancer appliance, the guys over at teamix seem to have taken that to heart and implemented a rather nifty thing for their new release.
It’s called “Port forwarding“, which is basically what you’d figure from the name. It bounces ports around the load balancer, but saves you from creating a separate virtual server (and adding the physical servers to that one), but also saves you from modifying the syslog-ng configuration on the balanced servers.
PacketPro 450 and SSH checks
Posted on Sunday, 5th August, 2007 in Life
As apparently the guys at Teamix read my recent blog post about their cluster solution, someone of their technical support called me on friday at work 
And pointed out
- That I’m free to express my thoughts about their product (which I recently did)
- That there is a better way to workaround this issue
He also said, its something which they had asked multiple times. It’s as simple as editing the Virtual Server and changing the service inspection from “Connection” to “None” .. *duh*
Don’t get me wrong, the previous rant simply originated from the logs filling up within three day. I still like the PacketPro.
Bloody cluster solutions (continued)
Posted on Thursday, 12th July, 2007 in Life
So, as the previous try on getting the teamix people to fix the bloody LoadBalancer (as in sending at least an identification string for the SSH check) didn’t work so well (they told me, I should configure MASQuerading/ROUTEing on the PacketPro (which is kinda icky), I went on today and looked at what SLES10 installs as default logger.
Surprisingly they install a rather new syslog-ng (well, syslog-ng-1.6.8 is what they ship) so it was rather easy to workaround the situation.
Here’s what already was in the syslog-ng.conf.in (more on that later):
filter f_iptables { facility(kern) and match("IN=") and match("OUT="); };
filter f_messages { not facility(news, mail) and not filter(f_iptables) };which I just extended with the following:
filter f_iptables { facility(kern) and match("IN=") and match("OUT="); };
filter f_messages { not facility(news, mail) and not filter(f_iptables)
and not match ("Did not receive identification string from 172.16.(123|234)");
};Afterwards just a quick SuSEconfig -module syslog-ng, restart the syslog daemon and the messages were gonse. Sure I know it’s a rather ugly hack 
, but since they refused to provide a “true” fix and it seemed like that question has been asked more than once it works for me, so *shrug* 
But now you’d ask why syslog-ng.conf.in ? Simply because Novell figured it would be too easy to just invent things like CONFIG_PROTECT for RPM/YaST, so they placed yet another file in there; from which the syslog-ng.conf files is generated every time SuSEconfig is being executed (that’s like every time you install a package using YaST).