Over the past couple of weeks I’ve been helping my fiance start up her own online store and business. The trouble with this is I know Magento is a big-name player in the field, but having first-hand experience with it in the past, I was less than thrilled about setting it up. I was really wanting to run a Python store, so I looked at ones like Cartridge, but the install for it was less than stellar to say the least. So, I ended up catching my eye on Presta Shop and pretty much fell in love with it right away.
It has an API that you can use, which was great as I was wanting to add products and the database structure was nothing but normalization. You could associate products to multiple categories, and since it’d be housing multiple types of products (i.e.: different cards), I wanted them to be able to be a part of different sections. Administration also isn’t bad either, as you can easily install plugins, modules, themes, etc…
However, Presta Shop has a few short comings as well. While it has an API, its very troublesome and error prone (which I will dedicate a whole section on its own to). Installing themes, while easy, can also easily break the layout you have. Also, it runs via PHP and uses Smarty as the template engine for themes. I really didn’t want to use PHP due to performance issues, and Smarty’s template system is…horrible in my opinion. But, I’ll get into this in the appropriate sections.
This series of articles is going to touch on my sysadmin experience of PrestaShop, and at the end I’ll provide a conclusion on what I think of it.
Want to make sure your server is up? Dying to know why the load is 5+ on a 2-core VPS? Using monitoring software.
Yes, it generates overhead. Yes, it is a pain to install and configure sometimes. However, when you want to know why something is breaking or how something is happening, it can be your best friend. Nagios and Cacti are two that I swear by daily, and love using for every bit of usage I can drain out of it.
Software like Shorewall is awesome. It makes managing software firewall easier than eating pie without a fork. However, it has one issue: global variables.
A good example of this happened to a friend not too long ago. In the config files existed some variables (we’ll call them SOME_NET and ANOTHER_NET). However, they were never defined anywhere. Not even doing my favorite grep -r -H “\$SOME_NET” . did any good. As far as I know he still never found out where or what it was defined as, but the horrific troubleshooting still seemed too unfair.
Learn where variables are set, and please keep it there.
When creating configuration files for software you’re writing, do not make it so difficult for the end user to edit them.
Naming a variable “window_x_pos” or “fullscreen” is easy to understand and know what it does. Naming a variable “deep_dark_interesting_option1041239” is like taking a sword and driving it through a table and hoping to make it go through…it doesn’t make sense.
This will probably be short, but should still be addressed. When you are configuring systems, don’t make the implementation convoluted. It won’t fair well for you in the future when you have to troubleshoot.
When I had to reconfigure my servers due to data loss, I wanted the channels to be secure. Well, making a long story short, I made it so ports 143/tcp and 25/tcp required SSL/TLS. That’s fine, normally. Small mis-hap in configuration but easy to handle. Not when you have to spend 4 hours trying to get software like SquirrelMail to be able to connect to tls://mailserver.domain.tld:25. Granted, the configuration for SM 1.4.x is annoying anyways, but none of it even made sense.
Swipe, founded by one of the founders of Twitter, I feel missed the bullet on one important service: Twitter. Twitter is meant for microblogging, and socializing. What better way to get the word out about a product than by social media, right? That’s where Chirpify comes in.
Chirpify is a payment method based on Twitter, where you send out specially crafted tweets that are then fed to Chirpify, and it does the payment processing for you. It also lets you sell things as well, which is nice. Its like the new eBay, but also on a lower scale.
One of the best features about it is you don’t have to enter your card information when buying. Instead, the information is entered on Chirpify’s website and is stored there. So its kind of like paying for something on eBay with a PayPal account. You give PayPal your card and/or bank info, and then when you go to pay for something, you just tell it what to use. Similar to Chirpify, just less annoying (don’t have to log in to pay).
I feel this can really help improve businesses, but it would be difficult to implement in store. What I would like to see is the ability to have a list of things that were bought by a phone number, and there be a dedicated employee who checks the user’s phone number against a database. Any issues that arise can be solved by the user pulling up a screen on their phone showing what they paid for, how much, date and time. Is this more work? Yeah, but it is still a viable solution for the market.
I’m sure you’ve heard of Swipe before. A device you plug into your headphone jack to swipe cards and make payments. It’s pretty flexible and intuitive, and is created by one of the founders of Twitter, even. They’re also one of the most cost effective producers as well (they give their device for free, while most others you have to pay for it).
Its interesting to see where Swipe has taken taking payments. They’re trying to revolutionize having to give the waiter/tress your card just for them to take it away to a register somewhere, swipe it and such. Instead, they could do it right in front of you without issue. Fun and awesome, right?
The problem is in security. To make a long story short, Swipe doesn’t make the action secure, as it relies on the audio channel and just fetches the noise. Audio in itself is insecure, so why would something using it be secure?
A better approach would be a USB-based device that did the same thing. However, two issues with that:
1. Costs more
2. Android 4.0+ by default doesn’t like things plugged into the USB (tighter security)
So what is one to do? They can always go with a different medium, and one that is actually pretty surprising. In our next article!
Smartphones are a growing essence in the world of everyday use now. Almost everywhere you look you see someone with a smartphone and they’re Facebooking, Tweeting, etc… on it. Heck, the only person in my age group (mid 20’s) I know of that doesn’t have one is my fiance. Though, she does have a tablet.
So, why aren’t stores picking up on this growing trend? Most of it has to do with cost.
Think about it, they use point of sale (pos) systems. Many very low-end machines that are tied to a mainframe or 10, which handles the transactions. They have been in place since the beginning, and only in the last decade have really began accepting credit cards. Look at the self-service scanners, and how long it took to become popular. Even when I was a kid I thought we would’ve had such technology by 2000. Where I live, it didn’t happen until around 2007.
I do remember, though, when I went to Maryland not too long ago. I took a cab, and they accepted credit cards. Now, before anything, the last time I experienced this, it was in Columbus, OH with the taxi driver having one of those card swiper things from the 80’s that imprinted your card on a receipt. So, I figured that’s how it would be in Maryland…nope! They used Swipe. Boy I wish I knew that before hand, I wouldn’t have carried cash. But, it was what it was. It was also interesting to see how different places are taking technology.
Retailers should start really considering it as well. They already accept payments online. The trouble, as said, is that they would have to basically rebuild their entire infrastructure, which could cost millions if not billions. Its had to weigh out the return on investment of something like this when there’s no data to go off of. But its impossible to build up the data because everyone is afraid of doing it.
While stories like these tend to get old to me, this one is an exception, because it shows that a dog’s old tricks can still prove to be worth points.
Now, there’s two people at fault here, in my eyes:
1 – Adobe: The exploit’s been there since AcrobatPDF v9. While not every bug will be found, I have a hard time believing it was safe for that many years (going on 5 years [2008-2013] now).
2 – The government agencies: I just have this increasingly sinking feeling that this is due to them still using v9, when v11 is out in the public as stable now. Why?
The article also mentions the attack being found in America as well, but doesn’t do much to touch on it. I guess which makes sense, since most of the attacks in the article are in the EU. But, in the article, it states that the writers found a way to bypass sandboxing. This isn’t new methodology, and in fact is quite old. So, why haven’t these been fixed? Heck, Adobe’s software has been under the gun quite a bit past few years due to countless number of attacks (think Java). Every month there seems to be a new 0-day out for one of their products. I feel moving to a different PDF reader, though, won’t fix the problem. PDF is a pretty standardized format. The issue should be addressed of the readers themselves detecting corrupted PDFs and not allowing them to load.
Is it that simple? Knowing my luck, probably not. But one can dream.
In a previous article, I wrote about how China is playing the wolf, and its not pretty. Going over the inbound traffic to their “great firewall”, I outlined some fine points…and now, we will address outbound traffic. This is something I also touched on in the previous article.
I mentioned before about 0-days existing on their servers. While it doesn’t always make sense to have the whole 9 years of security on a server (why have a virus scanner on a proxy server?), a firewall on these should always be installed and configured.
We’ll go back to Security 101. While passive firewalls have a place, restrictive firewalls are typically the go-to, and should be mandatory in government networks. You should only allow the traffic that needs to go through, and block out the rest. This being said, it seems a little implausible, though do-able, that America had a company such as Apache, set up a mechanism to allow a back door on only Chinese machines. Even more so due to Apache’s open source nature.
Yes, there is always the use of DoS attacks and the like, but governments everywhere (as far as I know) keep hush-hush about what actual attacks are done. You can detect all the DoS attacks you want, but it won’t prove beneficial to anyone.
Truthfully, and I’m sure a lot of people will agree, the whole risk of China being attacked sounds more like them being a baby, when it’s also been widely reported China has whole divisions dedicated to hacking countries. I’m sure America does too (NSA?), but we keep it more quiet as well.