Sunday, September 25, 2011

OK - I'm an idiot

When I first signed up for EE my account was deleted and I had to bug Ms Ally to prove I am not an evil wicked despicable spammer.

When I signed up for their forum so I could hear all the teases there and play the Cock Market game, my account was deleted and I had to bug MS Molly to prove I am not an evil wicked despicable spammer.

That however may have actually been a good thing, damn she's hawt! Now on my ever increasing radar of Enchantrixes I have to find a way to call.

Today while futzing around on my server, the reason I was tagged a spammer became clear. I never set up reverse DNS for my mail server. The reverse DNS for the IP addresses (IPv4 and IPv6) associated with my MX record still point to my colo facility, a completely different domain.

Now, if I was not the admin then it wouldn't be my fault, but checking the ptr record is a very common way to determine whether an e-mail is legitimate or possibly spam, and any decent mail system administrator knows this.

Plus 5 to LDW for using such a technique (I assume that's what they did) to help weed out the spammers, and minus 5 to me for not finishing the job on my own mail system.

Sunday, September 11, 2011

Path to RHCE

I do not have an official *nix certification. Back in 1998 I started playing with Linux using MKLinux DR3 on my 233MHz Beige G3 sporting 32MB of RAM. Unlike MacOS 8, Linux never crashed. I was hooked.

1999 I took a few classes based on Red Hat 5.2 (not RHEL 5.2, pre RHEL) and the company hired me as a Linux consultant. I made major bank the next few years, before the crash, but I never actually got my RHCE.

Now I mostly do PHP/PostgreSQL web programming, some sys admin work. Fixing bugs that other coders make, working for a lot less than I'm worth because there are smart intelligent capable people in other parts of the world (IE India) I have to compete with, and their cost of living is lower.

So, I'm in the process of starting a new company to market a DOMDocument based CMS I am working on. In addition to offering simple web hosting, I also would like to offer system administration of CentOS systems running my software, for companies that need more than just a CMS.

The that end, I thought it would be helpful if I actually work towards achieving a bona-fide RHCE. Took the assessment stuff. Some stuff I have forgotten, some stuff I do differently than the "Red Hat" way. But here's the results:

Configure Local Services: Substantial Knowledge
Manage Physical Storage I: Deep Understanding
Establish Network Connectivity: Deep Understanding
Administer Users and Groups: Some Understanding
Secure Linux File Access: Familiarity
Manage Files from the Command-line: Deep Understanding
Essential Command-Line Operations: Substantial Knowledge
Managing Simple Partitions and Filesystems: Some Understanding
Managing Flexible Storage with Logical Volumes: Substantial Knowledge
Controlling access to Files: Some Understanding
Installing and Managing Software: Some Understanding (Bull shit - I'm an RPM guru)
Tuning and Maintaining the Kernel: Deep Understanding
Enhance User Security: Substantial Knowledge
BASH Scripting and Tools: Familiarity
Network Configuration and Troubleshooting: Familiarity
Administering Users and Groups: Familiarity
Manage System Resources: Familiarity
Installing and Managing Software: Deep Understanding
Administer Remote Systems: Deep Understanding
Deploy and Secure File Sharing Services: Deep Understanding
Managing SELinux: Deep Understanding
Managing Simple Partitions and Filesystems: Familiarity
Logical Volume Management: Deep Understanding

I don't agree with all of it. Some of the questions were bull shit, IE questions about setting permissions in the GUI using Nautilus. Who the fuck uses the GUI to manage users and permissions? Windows admins maybe, but no UNIX guru does.

I'm not sure why it didn't rate me higher with package understanding. There are not many people who know more about proper RPM packaging than I do. Well, the test asked a lot of questions related to specific switches to the rpm and yum commands that no one ever uses, so I guess I may have missed some of those. They are needed so rarely, you look at the man page or use the help switch in the rare occasion you need them. But I digress.

BASH - I use to be a lot more fluent in BASH than I currently am, but BASH really isn't used for all that much anymore. Mostly simple crap. Anything with complexity is typically done with perl or python these days.

Anyway, it identified what I need to review. I'm going to try to review on my own, skip the RHCSA course, and just take the exam. Then I'll probably enroll in the additional courses needed for RHCE

Thursday, September 8, 2011

IPv6 - let the migration begin

For the unaware, an IP address is the address of a device (such as your computer or a web server) on an IP network (such as the Internet). When you go to a URL (IE web site address), the IP address associated with that URL is looked up and the IP address of that resource and is used to communicate with that resource.

Right now, most of the Internet uses something called IPv4. IPv4 is an old standard. It has some design flaws, including not enough IP addresses to adequately cover current demand.

IPv6 is intended to replace IPv4. It solves a lot of the design problems with IPv4 and it is highly unlikely it will ever run out of available unique IP addresses.

I have known about IPv6 for over a decade, but I just recently started migrating to it. My web servers are now all running IPv6 (as well as IPv4) and my home network is ready to go IPv6 but I need to replace my router.

Non technical people probably should wait until their Internet Service Provider starts offering IPv6 but for the technically inclined, if you are not yet IPv6 ready, have a look at They have a FREE program to help you get up and running both from home (even if your ISP does not yet offer it) and on your web servers. And if you complete the program (reach level of sage) you get a free T-Shirt!

I started the program yesterday, and got to Sage in a single day:

If you need an IPv6 ready host, check out Linode - Excellent customer service, and most of their data centers will assign you both an IPv4 and IPv6 address for your account.

Wednesday, September 7, 2011

Pictures of Rescued Kitten

I did manage to rescue the kitten I blogged about on the fourth (see September 4) - She was not born feral, too healthy and warmed up to me too fast.

Here she is:

Isn't she just adorable?

Sunday, September 4, 2011

Feral / Abandoned Kitten

There's a kitten living in the bushes in front of the local bar. The bar is currently closed for renovations so fortunately there is not a lot of traffic in its parking lot.

I'm not sure if it is feral or if it was dumped there. It is definitely alone. Friday night was when I first encountered it, I heard it meowing and I responded, and the two of us meowed back and forth but it never showed itself to me. It clearly is quite young, so I bought some whiskas pouches for it, they are easier for small cats to consume than dry food. I was worried it would need KMR. It did not come to the bowl while I was there, so I left and came back 20 minutes later and the bowl was licked clean, poor thing.

Last night (Saturday) it was still there. Again we meowed back and forth but again it did not show itself. I put food out and I finally got to see it's eyes but did not want to approach, so I pushed the bowl in further and it then did approach and I could see it, but it was too dark to make out much information other than it is quite young, I'm guessing maybe 6 weeks.

I just went back at 4 in the morning (my time) with another pouch. This time I did not need to push it all the way in for it to come and eat. It appears to be a tabby but it *might* be a tortoise shell. I am leaning towards tabby though.

Hopefully tonight or tomorrow early AM I will be able to coax it close enough that I can grab it and bring it home. Unfortunately I can't keep it, my community has a 1 pet rule and I already have 2 cats. But at least I can run a flea comb through it, get it de-wormed, and see if I can find a home for it.

If anyone on my friends list happens to live near Redding, CA or knows someone who does, and would be willing to take a kitten, please let me know. If I can not find a home quickly, it will have to go to the county shelter where it will likely be euthanized, which I suppose is better than starving to death, but still - I would like to see it get a home.

Thank you.

Monday, August 15, 2011

Jokes about Homeless People

I like irreverent politically incorrect jokes. They make me laugh. Sometimes when watching Sarah Silverman, I laugh so hard I almost lose consciousness.

However, as with any form of humor, even politically incorrect humor has some lines that just should not be crossed. One of those lines is jokes at the expense of homeless people.

In the last 24 hours I have seen two such jokes on twitter from different comedians. I don't recall seeing any others in a long time, I hope it is not a new trend that is starting in the comedy world.

There just is not anything funny about homelessness. It's not funny that someone has to sleep on the ground, under a bush, under an overpass, exposed to the elements and bugs and spiders. It's not funny that they are subject to the elements, such as wind and rain and heat extremes. It is not funny that they have to dig through garbage cans looking for enough plastic bottles to make a little money. It's not funny that they can not afford to have their teeth cleaned, and do not have facilities at their disposal to adequately brush their teeth, let alone wash their hair or even remove the most basic body odor from themselves. It's not funny how many are homeless simply because during this recession, some employers are automatically rejecting applications from anyone not employed elsewhere at the time of the interview. It's not funny that some are homeless because they have a mental illness, which may even be the result of post traumatic stress resulting from things they saw or had to do while wearing a uniform serving this country. It's not funny that some are homeless because they grew up in the poor part of town with crappy schools that did not even teach them to adequately read, let alone prepare them for college or even trade school. It just is not funny.

If you insist on writing or telling jokes at the expense of the homeless, please do me this one favor:

Pick a night, and go to your local soup kitchen. Volunteer to help serve the food. Once you have helped serve the food to them, serve some to yourself, find a spot at a table, sit down, and eat with them. Talk with them.

Then see how eager you are to write or spread jokes at their expense.

Friday, July 15, 2011

Un-necessary Deprecation in PHP

This blog is a gripe. A whine. I'm bitching. Just a warning.

Sometimes it is necessary to deprecate functions and change how a programming language works. Other times, it makes little or no sense.

Manuel Lemos of blogs about a coming change here: The Plot to Kill PHP MySQL Extension. Read his thoughts, they are better phrased than mine.

While not my personal choice, MySQL is without a doubt the most widely used RDBMS in PHP web applications. It has a long history with PHP and numerous web applications currently use the very PHP MySQL Extension that is on the chopping block.

As Manuel points out, there are other ways to connect to MySQL. Many web applications and classes however use the extension that the PHP developers wish to deprecate. Deprecating the PHP MySQL extension is a bonehead move. Are there better ways to do things? Absolutely. Should web developers update their code to use these better methods? Absolutely. Is it still a bone headed move to deprecate it? Absolutely.

From my point of view, the problem is cost. Someone has to go through the code and make all the changes. Then once all the changes have been made, the code has to be tested. If the web application is actively being developed, the developer should update their code base, but not all web applications are actively being developed and there are many cases where using updated versions from the vendor is not easily done.

For example, I use the search engine sphider on some web sites I maintain. I hacked the crap out of it to beef up security, make it output DOMDocument nodes instead of raw HTML, did some major hacks to the admin interface to fit sphider administration into the general web site administration and remove options that would only confuse the non tech people using the admin interface, and some other tweaks.

Sphider (at least the version I started with) uses the very MySQL extension that is on the chopping block. Now I will either need to fix sphider for these web sites, get an updated version of sphider and hack the crap out it as well, or implement a different solution to site search. I like to be a charitable guy, but I do not work for free. All three of those options are going to cost someone some real money when the next version of PHP released and the boss wants to know why the apache log is full of deprecation warnings.

Yes, this highlights the importance of using database abstraction. No, most web applications do not use database abstraction (wish they did, make it easier for me to run stuff on PostgreSQL without needing to hack it) and there are a lot of legacy web applications out there that will break when this module is no longer available.

This is the kind of move that makes PHP expensive for companies to use, and the PHP core developers really need to think about this.

Wednesday, July 13, 2011

Web App Security and Configuration Files

One of my biggest pet peeve's since I got into php web application development is the insecurity of many popular web applications out of the box. I am not going to detail all the issues in this post, just one that really gets under my skin: The security of the configuration file.

Most web applications use some sort of database backend. At a minimum, the application needs a configuration file to tell the application what host the database is running on (often localhost), the name of the database the web application is using, and how to authenticate with the database. Usually the configuration files contain a lot more than just that.

In the interest of trying to get the web application installed on as many servers as possible so the developers can have bragging rights, they often spend a great amount of time developing web based administration tools to these configuration files so that people who do not know what they are doing can throw the web application up on a server somewhere and start using it. Unfortunately, many if not most of these developers do it wrong, putting their users at an un-necessary risk.

The problem? The config files are written in PHP, parsed by the web server as PHP, and the web server has write permission to the configuration file.

Never ever give the apache user write permission to a directory it serves or a file it executes. This is very basic security, so let me repeat that. Never ever give the apache user write permission to a directory it serves or a file it executes. Doing so opens you up for the possibility of a remote exploits.

Unfortunately, that is exactly what many of these web developers do, often even instructing the user to chmod 777 the configuration file.

When installing a web application, there are several things you should do before the web application ever goes live:

A) Always make sure configuration files are outside the web root. If you do not know what this means, either educate yourself or hire someone who does know. If configuration files are in the web root, a mis-configuration of the apache server or a bug in the apache server could result in the configuration file being served to a cracker. Making this change may require you tell the web application the new location of the configuration file, but that can usually be accomplished with a simple sed expression.

B) Always make sure the the web server does not have write permission to the configuration file. This may break web based admin tools, but most configuration files are easy enough to understand that you should be able to simply edit them with a text editor (ie emacs, vim, etc.) when you need to make a configuration change.

Do those two steps, and your web application install will be a lot more secure.

Unfortunately, it sometimes isn't that simple. You may need to make the admin interface available to other people who do not have shell access to the server, or otherwise should not be hand editing a configuration file.

In those cases, what I tend to do involves porting the configuration file to XML. XML is a great way to store configuration information.

You will need to write a php script that loads the XML configuration file and extracts the configuration settings. This is easily done with the DOMDocument facilities that should be available in any modern php install.

Once you have properly created an XML format for storing the configuration options and a script to load it and take what it needs, you will need to re-write the admin interface to change settings within the XML file. Again, this is easily done with the DOMDocument facilities of php.

Finally, you need to protect your admin interface from potential system crackers. The admin interface should only be accessible over an SSL connection. It is a good idea to use apache authentication to protect the directory that contains your admin interface. I like to use AuthType basic authentication with a .htpasswd hash. If the web application has its own user authentication, you can use that as well but do not use it in place of apache authentication. If your web applications authentication system has been compromised, use of apache authentication may still prevent the cracker from modifying your web applications configuration.