For the past week or two now I’ve been working on an application to help monitor systems and services. Kind of a bastard child of Nagios and Cacti. There’s a few reasons why I’m “reinventing” the wheel, so to speak. But, I’ve decided to post here explaining the details, trials and tribulations, as well as any other random tidbits of information to toss in as well. Some of these will most likely also be cross-posted to www.securityfor.us as well, but a bulk of the stuff will be posted here. Anyways, on to why I’m doing this…
Nagios is a great tool. For years I used it myself. Its very powerful, integrates with virtually anything you can access via SNMP or scripts, and the documentation is pretty easy to follow. There are two main points of failure in terms of usability, though, that I find.
First, there’s the fact that its written in compiled CGI (or C, can’t remember now). With a strong background of “open source” initiatives, this surprises me thats it has lasted so long in the field. Its akin to running Microsoft Office via WINE; it works and does its job, but there’s better (or more suited) alternatives. If something goes wrong, you have to wait for the Nagios team to fix it, unless its a script to check for service/host status.
Next, there’s no ACL built in. I’m not sure why this is, but essentially Nagios relies on you running Apache (or something else that provides an authentication method like an LDAP module). Writing even a moderately functional authentication system takes a day at most. I’ve never been able to understand this aspect, and I feel it hurts the rest of the usability by not being able to segregate who can see what.
There are more reasons with Nagios that sparked my interest in writing my own monitoring set up, but I want to also address the software that this is more or less based on, Cacti.
Cacti, at least to me, is more of a RRDTool learning tool or assistant than an actual monitoring solution. It helps you create RRDTool graphs (which can be a major pain at first), and thats about it. If you really look at it, about 99% of its functionality revolves around building RRD graphs. Which is great, I even use RRD graphs in my set up as well. But, what else does it bring? Products like Centreon, that rely on Nagios on the backend usually, offer graphing as well, on the same platform (PHP) and is more actively developed.
More or less, I also touched on this with Nagios, but Cacti is developed in PHP (granted, open sourced). Why I mention this is because from my stand point and feeling, PHP and CGI/Perl are absolete languages when it comes to web development. They do have their place, don’t get me wrong, but the overhead and slowness of PHP, and the over-abuse of extending a language beyond its intents in CGI/Perl is just wrong.
These are a couple of reasons why I decided to roll my own solution. It has what is currently out there, offering more, while more or less requiring less overhead. A normal Cacti installation is difficult to run efficiently on a 256 MB VPS with 256 MB swap, and Nagios just causes more overhead the more it has to monitor. While the same can be said for Python, the integrations it has with different tools and the like makes developing on said platform a lot easier. This is what most of these articles will be covering as well.
As I’ve been working on this for a week or so now, I already have a couple of more articles I’m going to be writing tonight, as I’m heavily enduced with caffeine and nothing else to do as I can’t program on laptops (they annoy me greatly).
Earlier this year (this month?), BackTrack developers announced a new version of their distro, but this time seemed completely re-developed, called Kali.
Its a nice distro, and is based on Gnome 2 (MATE??). It has more tools than you can ever imagine, and from my experience so far runs pretty smooth. Though, getting Virtual Box’s additions to install can be a little annoying.
To be honest, there’s not a whole lot to say on this, just that the name seems cooler. It still has a plethora of hacking tools to mess with, and they seem to have trimmed the selection to a more recent and viable use. But, it doesn’t really add much, besides disk space. That’s also one of my biggest complaints on BackTrack.
It tries to be a one-size-fits-all solution to pentesting, which is nice, for professionals. I’m talking about people who go out to various enterprises and charge $150/hour just to click a mouse a few times. But for those more focused on the SMB side, you’re never even going to look at ~50-60% of the tools on the disc. So you’re pretty much left with either reimaging the distro, or building your own.
Kali has a strong potential, but I feel it’d be better if they left it more up to the community to choose what they wanted on it instead of trying to be a swiss army knife.
I’m a strong opponent of using password managers. To me, they’re nothing better than writing info down on a post-it note. You know sensitive info is there, but they just use security by obscurity. However, as I’m also a strong lover of the CLI, I thought it was interesting that a CLI-based password manager for Linux is out there, named Pass: https://liquidat.wordpress.com/2013/03/27/pass-a-perfect-shell-based-password-manager/
The basic rundown is on install, it has you create a GPG key, and with that key it encrypts data in its “store”. It tries to store one login per file, but you can change this by either editing the file itself or running pass insert <folder>/<file>. This can make it easier, or harder, for you and any eavesdroppers.
Another thing to like about this one (or hate) is that it has built-in support for Git. So, if you want to have a repo somewhere that stores your GPG-encrypted passwords, you don’t have to worry about much. Once you edit a file via pass, it calls the git add and git commit programs automatically to save to a local repo.
Other than this, there’s not a whole lot to write about, it saves your passwords and does it using a GPG key. Its a nice twist, but no different than any other password manager out there.
So apparently someone decided to build a Linux distro (boy, how many do we need of those, huh?), but this one isn’t based off of Debian, Ubuntu, Cent, etc… Nope, this one is based off of OpenSUSE, and its dubbed CalamariOS: http://ostatic.com/blog/calamarios-huh-what
I wasn’t exactly a fan of OpenSUSE before (it hated my dual-monitor set up), so I haven’t even tried it in the past year. But, I feel this can open a larger market to distros. It does get tiring seeing “hey, we just built a new distro based on Debian/Ubuntu and want you to try it!” So, I applaud this as a wonderful move forward in functionality. OpenSUSE never has really held much ground, however, which makes me sad for this project. But, who knows…this could be the steam needed to get SUSE up and going.
The two major turn offs for me on this, though, are Gnome and it comes preloaded. I’ve been using Arch for a few years now, and love the fact I get an almost barebones OS. Though, Arch is starting to go the way of the others too (I don’t need reiserprogs when I’m using ext4…just saying).
Time will tell on if this is going to be another dead project, but its definitely something to keep an eye on.
I remember back in the late 1990’s and early 2000’s, phpMyAdmin was the go-to way to manage a MySQL database. Even to this day a lot of people swear by it (and at it). But, especially if you’re working in a mixed environment that runs MySQL and PostgreSQL, for example, a single solution is better than running two different set ups.
My personal choice, even for MySQL now, is Adminer: http://www.adminer.org/
Its really a nice piece of software. A single PHP file, easy to theme, and connects to multiple database types. Granted, I mostly use it for Postgre, but its also a viable solution for MySQL and SQLite as well.
The interface is also pretty easy to work with as well. Its got a similar feel to phpMyAdmin, but its not as overly featured. It does what its intended to do (manage databases) without throwing in all these options to manage the server itself. Which, if you’re a DBA, you may or may not enjoy, but for a developer its more bloated than anything.
If you’re looking for a way to actually manage your database without managing the server, Adminer is about the best solution you can ever find.
SKYnet has been here for a while, but now we’re looking at SKYnet v2. Terminator edition.
No, I don’t want my car to update my Facebook status to let people know where I am. It’s already a horrible stalker medium as is. No, I don’t want to listen to what my friends are. Also, who thought it’d be a good idea to present information on a HUD (heads-up display)? This isn’t a first person shooter, this is driving. How is it safe?!
I’m sorry but long story short, I see no good coming from this. Its awesome on what they’re doing and how Ford+Facebook+Google are working together…but, I don’t see how it benefits the driver. How does it benefit me to have someone make an app to tell me when to get gas? I can look at the gauge and figure that out on my own. If the gauge is broken, wouldn’t the app be broke as well? Fix what we have now and worry about making a new shiny toy later.
I feel in this category, PrestaShop really shines. Its basically like a real store inventory system, and its amazing. With the power of Ajax, it gives you so many options without throwing it in your face at once. They’re separated by tabs on the left side, which makes it easy as pie to go to a specific part of the product and manage it.
In short there’s a lot of features that I won’t cover here, but is definitely worth looking into. You can specify if the item is online only, pre-tax price, what the tax is, etc… Can add more images, different properties/information, reference IDs (i.e.: SKUs). It will also keep track of your inventory, so if you want to make your job easier and run both a physical and online store, you can easily pull information from the database (the API is easy for this).
Overall, in terms of actually running a store, its pretty nice. Its like back in the day when you knew how much everything was and where everything was placed, you could price it off the top of your head. If this area was bad too, then I’d suck it up and go with Magento, but this is basically the saving grace for me for Presta.
One thing I’d like to cover though is that Presta does integrate with eBay. However, it only supports the France and German versions of the site. The eBay API isn’t horrible to work with (similar to PayPal’s if you have ever used that), but while there’s a huge demand for a UK and US support, the Presta team seems very hesitant on doing so. This could be due to the fact that Presta is based out in the EU nation set, but how that affects eBay’s services to them I don’t know.
As I mentioned before, the template system is based on Smarty. I’m not well-versed in how Smarty works or anything, but I can say this: Presta has turned me off from it.
PHP itself is an annoying language at its core. There are so many restrictions and fallacies it has that its almost not even worth it with the improvements of both Ruby and Python. Its like the HTML of scripting/server side languages.
The problem with the Smarty template system, though, is that Presta requires it to be compiled to improve speed. Which would be great, but if you don’t enable “force compilation”, you’re going to run into a lot of messes then. But, it seems even in doing so, I’m still having issues.
I went to install a theme, which went fine. However, the theme didn’t look anything like the demo did, so I decided to switch it back to the original for now. In doing so, the original theme became just as bad, if not worse. Everything was out of order, moved around, etc…
I can understand the compiling part of Smarty, since Presta is used a lot and I’m sure a good collection of heavily-viewed online stores use it. However, I don’t feel it was implemented in a proper way. It feels…forced?
At this point, I don’t even know what I can do to fix it now. Or if I should just delete the whole thing and start fresh. Which I might do the latter (kind of out of boredom and frustration). The install was fine, just seems like everything else is going down the tube.
I couldn’t wait to write this section. The API is both a blessing and a damn curse rolled into one.
First thing, the API works by parsing XML both in and out. So, you poll the API service to retrieve a XML structure of data that you then manipulate and send back. Not a horrible idea, in theory.
I’ve never been a fan of XML for this purpose to begin with, but I’m not biased in this review either. Getting the data is a piece of cake. The problem comes in trying to figure out what you need to edit and what you have to take out. It doesn’t do it for you, its nothing but trial and error. Now, this wouldn’t really be a complaint IF the documentation would tell you. But the documentation for the API is just as vague.
Probably my biggest gripe, is the API helper they give you for PHP doesn’t technically support the newest versions of PrestaShop. You have to edit a line to tell it to support version 18.104.22.168 (which is the most recent at the time of writing).
Not only that, but as I said, the API is nothing but trial and error. I spent a good 4-5 hours trying to figure out why I couldn’t insert a product. Even when I enabled debugging/dev mode, the responses were nothing but “Error: 400. This means a bad request.” Okay? What bad request? Nothing in the error logs, nothing else spit out, closest thing I knew is it had to deal with line 214 in the API helper script. Yeah, not great.
Then, I kept getting an error stating bad parameters given. Apparently, there’s some fields that, even though it gives you in the XML, you have to remove yourself. Not very intuitive, and if it wasn’t for it had everything I wanted and I didn’t like the other solutions, I would’ve ditched it.
It gets better, and worse, though at the same time. Right now I still haven’t figured out how to properly add a new image to a product, but I’ll figure that out after Easter.
Going into this project, I knew the server (read: VPS) I’m using for it wouldn’t be very powerful. I had a custom OpenVZ container set up for me that had 256/256 (RAM/burst), 30-40 GB of disk space and ~400 GB of bandwidth. This is optimal for running a small shop, however, which is what it was intended for.
I knew right away when I decided on PrestaShop that I didn’t want to use Apache (which is what Presta recommends). I was already dreading the MySQL usage, so I was deciding on lighttpd and nginx. While I like lighttpd, I wanted to use something different, and went for nginx, as I’ve used it for proxy/load balance before.
The set up for it was pretty easy. Just add PHP support (I used PHP-FPM), and off I went to install Presta. The trouble with nginx (and lightty) though is that they don’t support .htaccess, and they both have their own unique way of handling rewrite rules. Luckily for nginx I found this website: http://winginx.com/htaccess that will convert .htaccess files to usable nginx lines.
Other than that, I had no issues, surprisingly. Install went smooth, set up the database and imported a bunch of test data. I was pleased. For install, I’d give it a 5/5.