Quick and dirty blog post for those people who are looking to get recent versions of ntop (5.x) running on CentOS 5.6. The main problem is that newer versions of ntop require Python 2.6 or later, and this requirement cannot be disabled compile-time. So the best solution is to simply build your own version of Python and install it.
This is all I had to do to get it working:
You do need the CFLAGS step in order to build Python modules that ntop can link against. Everything else with the ntop install is pretty straightforward in terms of solving dependencies. Happy netflowing! TL;DR Replace your init script with this one. It uses sudo to change to the RabbitMQ user before starting, stopping, and checking the status.
Here's a link that corroborates what I found: http://www.mentby.com/Group/rabbitmq-discuss/issues-on-rhel-62-with-rabbitmq-282.html We're doing an upgrade of RabbitMQ here at Weebly. Moving from a CentOS 5 single node to CentOS 6 with DRBD and Pacemaker. Going from RabbitMQ 2.old-and-busted to 2.8.new-hotness. How hard could it be? Well a few things. Alternatively, this post could be titled, "Mr. Smisek, your airline is in serious trouble."
I always raise an eyebrow whenever there's some sort of service disruption somewhere because someone says "the computers are down" or "the system won't let me do it." Chances are, they're just feeding you a line. The reality is that they don't know how to use the system (either lack of training or intelligence), or they just don't feel like working right then. Sure, systems do break, but not on the frequency that we hear about "the computers being down" constantly. We live in an age where someone sitting on their couch in Omaha can push a button and instantly trade billions of a foreign country's debt in milliseconds, but you're telling me that I can't pay for this taxi with a credit card because your reader is broken? Bullshit. I pushed the updates up to Github; go and check it out:
https://github.com/scurvy/OpenTSDB-UDP-Proxy I also changed the project name to reflect that it's no longer just a counter proxy. Yep, it now supports set (gauge) operations, too. So just to recap, if you want to keep track of counters and gauges over UDP and get that data into OpenTSDB, check out the proxy. It's pretty basic, but it works decently well. Couchbase is used for shared state/data, so you can deploy a mess of these things and scale up as traffic requires. We also now support dumping the counters out to a flat file. This is handy if you want to parse the data with something like OpenNMS for thresholding (we do). Enjoy and please send me feedback! Again, nerdy stuff follows. Click away now if you were looking for pics of naked chicks or something.
Like a lot of people buying new hardware these days, we've recently started to look into migrating from CentOS 5 to CentOS 6. New hardware really is the only reason we're looking to migrate. The new hardware isn't supported by CentOS 5 kickstart and rolling your own updates into a new kickstart image can be a PITA. So why not upgrade to the new stuff? How hard can it be? WARNING: nerdy ops stuff below
Want to add low-latency counter support to your app and already run OpenTSDB? Don't like how OpenTSDB only takes updates via TCP? No, I don't either. I wrote a hacky proxy to accept UDP increment and decrement operations and send updates to OpenTSDB. It uses a persistent intermediary to store the values before updating OpenTSDB. It's up on the githubs. Have fun. RTFM. https://github.com/scurvy/OpenTSDB-UDP-Proxy |
AuthorA NOLA native just trying to get by. I live in San Francisco and work as a digital plumber for the joint that runs this thing. (Square/Weebly) Thoughts are mine, not my company's. Archives
May 2021
Categories
All
|