It’s another HostingCon Goodies day – these exciting new free tools will get your website listed in Google within 24 hours – guaranteed. If your site’s already in Google, you will get even more pages listed, and improve your page rank in seven days or less.

Simply login to your DrakNet website control panel, look for the new SEO Tools category, and click on “Get In Google.”

We’re sponsoring your Attracta™ Basic-level SEO tools account at no cost to you. It’s yours free forever, and it normally sells for $59.40/year. If you wish to upgrade from basic, you can do so from within your control panel.

What’s in your free Attracta SEO Tools account? All of the tools and services you need to get more of your site listed in Google and the other major search engines, with improved search ranking.

Getting started is with Attracta is easy

+ Log in to your DrakNet control panel
+ Click on the “Get In Google” tool.

That’s it. 30 seconds of your time and you should see your site in Google within 24 hours.

Today’s blog post is guest authored by Janice Schwarz of GeekArtist Web Solutions, DrakNet’s affiliated Web Design Company.

In the 10 years I’ve been designing websites, I’ve seen good, bad, and ugly situations when it comes to website ownership. Today, we’re going to talk about the ugly.

When I take on a new web design client, one of the first pieces of information I ask for are the logins to the client’s web host. The responses I frequently get range from “OK, here they are” to “I don’t have those, my last web designer/employee/my cousin has them and I don’t know what they are or how to reach them” to “what’s a web host?”.

Many of my clients do not have the basic information they need as a website owner. It does not matter who you hire to handle your website affairs, if you signed up for and pay for the hosting and domain, then it is still your hosting and domain. All account logins are yours and you should have a copy of them stored somewhere. If you have a website made for you, you should have your own copy of the website too. A copy stored on YOUR computer and/or a CD, DVD, or portable hard drive. You don’t want your only copy of your website to live on the web server. This is a handy backup in case there is a problem that causes you to lose your entire website. And that can and does happen on occasion.

One thing to bear in mind though is if you need a domain (your own .com), be mindful of whose name it is in when purchased. For example, if you hire someone else to get it for you, did they pay for it and put their name on it, or your name? Because if they put their name on it as account owner, they own it. Did you have them sign up for your web hosting? If so, when they signed up, did they put your name on the account or theirs? If theirs, then they own it.

It does not matter if you are paying for it regularly. The domain registrar and web host MUST assign the account to whoever’s name is on the account. If your name is not on there and your web designer disappears, it is possible you may not be able to regain access to that information.

So remember: any time you have anyone handle your website needs for you, make sure that
1. Everything is in your name
2. You have all logins for those accounts
3. You have backups of your website.

Even if you host with my business, GeekArtist Web Solutions, LLC, and have us handle everything for you, we’re still going to make sure you have this information. If you tell me you’ll never need it and don’t want it, I’m going to tell you, “I have to send this to you anyway.”

It is YOUR website. So you are entitled to all the account information and should always keep that data somewhere you can easily retrieve it.

A number of folks have asked for alternatives to Soholaunch since we announced that we would cease offering licenses. For non-ecommerce sites, one of the best simple CMS’s out there is WordPress.

Yes, WordPress is the most popular blog software out there – but in reality, it does a whole lot more.

Setting WordPress to Serve a Static Page

Once you’ve installed WordPress from Fantastico or Softaculous, you log in to your dashboard (wp-admin) and scroll down to the menu on the left that says “Settings”. Within settings, you’ll want to click the link that brings you to the settings for “reading”.

After you get into the settings on reading, you’ll see a setting called “Front page displays”. Since WordPress defaults to showing posts because it assumes that it is going to be a blog, you simply need to change the settings to a static page that you have created.

If you are not going to have a blog at all, you can entirely ignore the Posts submenu – you can use WordPress and choose not to have a blog at all. If you want to have a site and a blog on a sub-page, you would create a main page, and then go into reading and set that page as the Static Page you wish to serve first.

If you want to have a blog as well, create a blank page under “Pages” with the Title “Blog” or “Company Blog” or something similar, and set that as the posts page so that it’s a sub-menu part of your site.

Why Use WordPress as a CMS?

WordPress does not tend to have the steep learning curve of most CMS’s like Joomla, and a site can usually be created, installed with a template, and launched by cutting and pasting content in very little time.

Because of the sheer obsessive popularity of WordPress, you can find a significant amount of very high quality templates, plugins, on wordpress.org explaining how to do this or that with WordPress, and if you don’t want to get too crazy/fancy, tweaks can often be implemented very, very easily. There are also a number of themes coming out now that are specifically designed to be used as CMS’s, and not strictly as blogs.

And another nifty feature – all those tweaks like caching and keyword plugins and so on that you would use on a blog can be used on the pages (your main site) as well.

Because so many people are using WordPress, the sheer amount of information being written about it, and how to use it, is enormous bordering on staggering. There are many bloggers that just blog about WordPress use on WordPress installations, and solely focus their blogging endeavors to explaining in simple terms how to get the most out of WordPress.

If you’re looking for a simple CMS to use that will produce a slick, XHTML/CSS site in little time with a huge amount of plugins and templates available for you to use at no charge, don’t count out WordPress.

Unfortunately, DrakNet has made the difficult decision to cease offering Soholaunch Licenses to our clients and supporting the software after December 1, 2010. The includes both our direct clients, and our Reseller accounts. Please note all those using Soholaunch should have received an email with regard to this transition this morning.

The dates are as follows:

As of September 1st, 2010, Soholaunch will cease being available in Fantastico.

On December 1st, 2010 Soholaunch licenses will cease to be commercial and will revert to free licenses for any installations that are not converted or moved.

We are leaving a three month time window to allow people to prepare for the change, regardless of what your decision is. You have a few options with regards to your site:

1) You can lease Soholaunch directly for $20 per month per installation and remain with DrakNet:
https://billing.soholaunch.com/cart.php?gid=1

2) You can purchase an owned license for $200 one time and remain with DrakNet:
https://billing.soholaunch.com/cart.php?gid=1

3) You can convert your site to any of the other 150 programs we offer in Fantastio or Softaculous.

If you are planning to convert your site, we will give you a secondary account at no charge for three months with it’s own cPanel that is a subdomain of DrakNet so that you can start with a clean installation and begin building. When you are ready, we can then convert that account to your original domain name so that you will go live. (Obviously, resellers can do this on their own).

4) You can move hosts to a host that offers Soholaunch to you at no charge – if they are a cPanel host, this is a relatively easy thing to accomplish with a full cPanel backup. If you’re unsure of who to use and you want to go this route, feel free to email us.

We apologize for this inconvenience that this will cause you, and we stand ready to help you utilize any of the options in front of you to the best of our ability even if your choice is to go to another host, so please lean on us for any help you may need during the next three months regardless of your decision.

Due to a number of recent exploits, we have begun locking down some risky PHP behavior by default. This information has been in the PHP FAQ for a couple of weeks, but we wanted to do a more inclusive blog post on it.

PHP By Default

The PHP settings by default include the disabling of the following behaviors that are known to be somewhat risky when used in conjunction with really bad code:

show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open, allow_url_fopen

What that means is that if you install software that requires any of these to be “on”, your software will not work the way that you want it to as the system will not allow those functions on your site.

Your Own PHP

You are not, however, limited to our security-focused PHP implementation. You can write support and let us know that you need to override settings. In response, we will copy the system’s php.ini file into phpini.txt in your home directory so that you can edit it. There are two ways that you can implement the above disabled functions on your site.

Per Directory

If you only have one directory that needs the function, the safest thing to do is to only enable something on that one directory because it limits possible incursion risks into your site. To do that, you would take the phpini.text and open it in an ascii editor (or using CPanel’s File Manager) and find the section:

; This directive allows you to disable certain functions for security reasons.
; It receives a comma-delimited list of function names. This directive is
; *NOT* affected by whether Safe Mode is turned On or Off.                
disable_functions = “show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open, allow_url_fopen”

And edit the disabled functions. For example, to do Soholaunch backups, the directory /sohoadmin/program/webmaster needs shell_exec, so you would edit the above so that it looks like this:

; This directive allows you to disable certain functions for security reasons.
; It receives a comma-delimited list of function names. This directive is
; *NOT* affected by whether Safe Mode is turned On or Off.                
disable_functions = “show_source, system, passthru, exec, phpinfo, popen, proc_open, allow_url_fopen”

Save the file as php.ini, and place it in the /sohoadmin/program/webmaster directory. For extra security, you can only upload it when you need to take a backup, and then change the filename or pull it down onto your computer and delete it to re-secure the directory.

This method will change only the directory behavior, and not the whole site behavior.

Change the Whole Site’s Behavior

If you need a function on more than one directory, or you’re unsure which directory you need the behavior changed in, you can easily change the behavior on the whole site without having to manually copy the php.ini everywhere.

To do this, you would use the same method above to change the php.ini, and then place it in your top level directory of /home/username/public_html/. Then, also in /home/username/public_html/, you would create a file called .htaccess, and you would place the following in that .htaccess:

suPHP_ConfigPath /home/username/public_html/

This tells the server that on this site, the php.ini in this directory is the one that the site should use, and not the server’s default.

A Word of Warning

There are various methods of changing php behavior floating around on the Internet, and one is the php_flag in .htaccess – please note since we run suPHP, that won’t work here. It will give you a nice error on your site if you try it, though, but best not to – trust us, isn’t going to work.

The other method we’ve seen some people recommend is uploading a php.ini file to a directory with only the behavior that you wish to change i.e. one line only as the entire php.ini file. This is bad. Don’t do this if anyone tells you to. It’s not correct even though it may appear to work.

PHP does not merge the php.ini files together, so when a custom php.ini is used it must contain all of the required directives from the main php.ini file (for example, if Zend Optimizer is required, the new php.ini must load the extension.) This is why you must email in to support so we can provide you with the server’s php.ini.

In computing, an iNode is a data structure on a file system that stores basic information about a regular file, directory, or other file system object. Each iNode has an number to identify it, and whenever you create a file or a folder you’re creating an iNode. Even if the file is really, really, really small.

For example, a fresh install of Joomla uses around 5683 iNodes – and that’s before you do anything else to it.

To set limits on “unlimited” hosting (don’t get me started), many hosts created iNode limits, and when you hit them, your host can take various actions like not doing backups for you all the way to kicking you off or forcing you to a VPS.

Disk limits didn’t really ever go away – they simply shifted from easily understood disk space space to not so easily understood iNode limitations.

Like almost anything else in shared hosting, 98% of you don’t hit this, and it’s not a concern. For those that do, though, it’s a big concern, especially on sites that tend to create a lot of files. Since people are starting to discover this hidden little clause in the “unlimited” offerings that abound, we’re starting to get questions about it, like:

With the higher disk space allotments, are you still going to do backups?

Are there new inode restrictions?

My other host limits inodes instead of disk space, and after a certain number they won’t do backups.

We do not, and do not plan to have, iNode restrictions as we don’t actually offer unlimited hosting and don’t have to put other restrictions on your site to keep you from actually using the “unlimited” space.

iNode numbers are also not a concern with regard to backups here at the moment.

Most cPanel hosts tend to do compressed backups – this means the entire site is packaged every single time it’s backed up (along with your email, your system files, and everything else), and that backup is stored somewhere.

Compressing huge web sites is incredibly resource intensive and can take hours for a full server, so shared hosts with clients that have huge and enormous sites taking up huge and enormous amounts of space run into an issue compressing those sites not just because they are huge, but because they have thousands upon thousands upon thousands of files.

DrakNet made a choice several years ago to cease doing compressed backups because of just how resource intensive they were, and we switched to incremental backups. What that means is that we compare the backup with your site and bring over only what’s changed – this is far more efficient from a resource perspective, though obviously it takes up far more disk space.

And so there you have it – no hidden inode restrictions, and due to the way we take backups, we do not plan to have inode restrictions on our accounts.

Before we headed off to HostingCon, we asked folks over on Facebook what goodies they wanted us to get, and several people asked for more software that could be easily installed.

Happy 2nd HostingCon goodie day!

DrakNet is now a Softaculous NOC Partner, and this new auto-installer has been installed across all servers and is ready for your use. You can find the Softaculous icon right next to its competitor, Fantastico.

In addition, we’ve also added Softaculous Voice Tutorials to the video tutorial section to help you out with installation.

The following software is available in your cPanel under the Softaculous icon right now.

The move of accounts from Blastoid to Espeon is now complete, except for four stragglers who decided to manage their own DNS. (If you were not resolving to the new server when we looked the morning and we found your custom DNS, we emailed you with what needs to be changed).

The problems of yesterday’s move with the databases was entirely our (ok, my) fault. In our focus on the containers and getting to know Cloud Linux, we miscalculated the combined amount of space needed for MySQL databases, didn’t double check, and filled the partition about halfway through the move. When that happens, database backends come to a screeching halt.

You guys really use an enormous amount of data.

We moved the databases to the /home partition instead of the smaller partition it defaults to, and due to the huge database usage you all tend to eat, the new machines will have that set up before we move anyone just in case we run into the issue again. The /home partition, since that’s where your web sites are, has the largest chunk of disk space allotted to it’s use and after combining the servers and placing the databases in it, Espeon has 178 Gigs used with 651 Gigs free on that partition. Hopefully, that will hold you all for a little while.

So, now that more of you are being plopped into containers, what should you be concerned about?

I have a really busy site, but I’m well within my bandwidth allotment – if I am under my bandwidth limit shouldn’t you just make my container bigger?

One site getting 3 Gigabytes of traffic a month can be far more resource intensive than one site getting 25 Gigabytes of traffic a month – it all depends on the site, and how its coded, and what it’s doing. In our TOS, we do (and have for years) place limits on those because despite everyone’s packages in the web hosting industry selling bandwidth and space, the real underlying thing that shared hosts have to be primarily concerned with is resources – CPU, memory, i/o. Those are the real numbers that matter. Space and bandwidth is really the least of the issues these days.

We will be reworking the allotments/formula there to better reflect the containers, and higher level accounts will have options to make their containers slightly bigger at no charge if they begin to outstrip their default container. But these containers are not infinite – even “the cloud” has a finite expansion point.

Once you max your container, if you are still slowing or “503ing”, you’ll know that it’s time to look at other options like VPSs, a server, a cloud server, a Hybrid, a high traffic service optimized for your software, or the like. If you have an enormous number of add on domains that are all somewhat busy, realize that they share a container, too, and it may be time to spin them off into their own account or get a reseller account just for your domain addiction. (Each Reseller subaccount does have its own container).

At the moment, we have containers defaulting to 15% of total server resources. On a server with a lot of cores, and a lot of memory, that’s a lot of resources. If you’re outstripping that, in our humble opinion shared hosting isn’t a good platform for what you are doing or there’s an issue with your site you need to address.

Joomla is an awesome CMS and lots of people use it. It’s also one of the most commonly exploited pieces of software we see.

Securing Joomla can be a chore, and telling you how to do it completely is beyond the scope of one single blog post – but like WordPress, one of the most common Joomla issues that we see are people downloading and installing plugins that are vulnerable.

As with WordPress Plugins, Joomla plugins can open up holes on your software and your site that exploiters can drive a truck through.

Check Before You Download

Joomla does it’s best to let you know about these plugins that can decimate your site – but you’ll only find that information if you go look for it. Just like folks who don’t read the blog likely have no idea we were at HostingCon, got new stuff, and are making major changes, folks that don’t bother to ever look at Joomla’s documentation but who actively use Joomla have no idea that there are plugins being offered that can cause real havoc with their site.

http://docs.joomla.org/Vulnerable_Extensions_List

Joomla lists extensions that are being offered which are (1) Vulnerable and obviously (2) you should not use if they are on that list. One of the extensions we’re seeing being exploited repeatedly is:

RSMonials

http://www.rswebsols.com/downloads/category/14-download-rsmonials-all?download=23%3Adownload-rsmonials-component

XSS Exploit
190610
Believed to be 1.5.1 version

It’s on that list, and it’s highlighted in a really nasty red so you comprehend this is a real problem, there is no patch, and you shouldn’t use it. Ok, so what if you do use it?

What is an XSS Exploit?

http://www.cgisecurity.com/xss-faq.html

Cross site scripting (also known as XSS) occurs when a web application gathers malicious data from a user. The data is usually gathered in the form of a hyperlink which contains malicious content within it. The user will most likely click on this link from another website, instant message, or simply just reading a web board or email message. Usually the attacker will encode the malicious portion of the link to the site in HEX (or other encoding methods) so the request is less suspicious looking to the user when clicked on. After the data is collected by the web application, it creates an output page for the user containing the malicious data that was originally sent to it, but in a manner to make it appear as valid content from the website.

Remember that anything you install is your responsibility to secure. Finding the holes and patching them are considered your responsibility and can usually be dealt with by simply making upgrades a part of your site maintenance. In Joomla’s case, they provide a current list of those plugins considered dangerous and exploitable for you. If what you want to use is not on there or if you want wider information, searching for your software or plugin and the word “vulnerability” will give you an idea what the issues are.

For example, the search RSMonials vulnerability brings up an enormous amount of information on the problems with this plugin:

http://www.google.com/search?q=RSMonials+vulnerability

and this “security technique” (i.e. the simple Google Search on what you are using with the word vulnerability) is, again, a cross-platform technique that can be used on and is applicable to any software or plugin, not just Joomla.

This technique can also be used by web site novices who can’t install anything that doesn’t come with a button.

If you are a programmer, you can always sanitize and plug the hole after reading about the vulnerability. If you’re of the button-click software user variety, this technique will tell you what you should absolutely not use. Vulnerable software is not something anyone should gamble on.

What does this all mean for my DrakNet Site?

While we let you know after your site has been compromised, that’s truly not the way you want to find out because the moment we find the exploit, your clock starts ticking.

Repeated exploits will cause your site to be suspended and/or terminated, and if it’s an active exploit returning daily reports and re-infections, you’ll have only four days to get up to speed before it becomes a risk of you losing your site – as a host, we cannot knowingly let a site continue to serve things we know puts people at risk. The fourth exploit in a week, and we will take the site offline, and potentially not allow it back on again.

Any site running dynamically (forums, wordpress) on software is susceptible to attacks, but Joomla particularly so – especially in the realm of released plugins by independent people not associated with the Joomla project.

If you’re going to offer dynamic sites, always be aware of the things that can go dynamically wrong, and take some extra steps before you install your own welcome mat for site exploiters. Security experts put a lot of effort into getting the word out, so make sure you take advantage of the work they put in to try and keep your sites and your visitors safe.

We came, we drank, and we bought.

We’ve been back from HostingCon for a few days, and we definitely came back with more than swag. And while the swag is cool, we think you’re going to really like some of the rollouts. Since HostingCon’s subject is the cloud, we’ll start with the cloud.

As of last night, Espeon’s OS has been switched from CentOS to CloudLinux, a Linux Operating system that was specifically created address some of the concerns of modern shared hosting environments.

Particularly, some of ya’ll’s tendency to explode and take down a server with ya, whether due to bad coding or sudden outrageous popularity.

CloudLinux delivers advanced resource management, better security and performance optimizations specifically targeted to shared hosting environments. This improved performance helps us provide better support to you by enabling VPS-like containers for your resources in a cost-effective shared hosting environment, guaranteeing that you get the resource you pay for and expect without “server hogs” muscling in and stealing what’s yours.

Ok, but what if I’m a server hog?

Well, to be honest, then this kind of sucks for you.

Once a website reaches the limit of resources which has been set, the site will begin to slow down. Once the number of entry processes (apache/http requests is reached), the user will get a 503 error message. The website that is consuming too many resources will stop working but the other folks on the server will continue to run normally with no slowdown.

We will still be able to attempt to help you tweak resources but at the threshold levels we set (which are significantly higher than the TOS limits), if you are consistently outstripping your container, it’s time to either take the add ons and spin them off into their own accounts with their own resources, or look to moving to a VPS or server.

Espeon, you are already in the Cloud.

As of last night, Espeon has been running in this new environment as it was the only one on CentOS 5 (it’s the newest). All other boxes are on CentOS 4, which is end-of-lifing in Feb of 2012, which would have necessitated 5 server migrations in any case over the course of 2011. Since we know it’s coming, we’re going to start this now so there’s only one blip instead of two and upgrade all OS’s to Cloud.

And if you don’t know what any of the above meant, just read from here on out, which is in English.

Because CloudLinux architecture is designed to guard against server density issues, leaving a huge amount of idle resources isn’t necessarily something we need to do anymore (and is not very green).

It’s also far greener to get what and who we can on the server as long as there is not a performance issue and any speed sacrifice. Since everyone is allotted their slice and will be lassoed in individually without affecting overall performance, we’ll be raising our resource ceiling and moving some (or all) of Blastoid over to Espeon and retiring Blastoid.

Once that’s done, we’ll then purchase a new machine and begin leapfrogging everyone over to new and better hardware and will gauge the performance thresholds as we go.

So, what makes this Cloud Hosting?

Honestly? We don’t have any freaking idea. We spent three days at HostingCon while everyone talked about “the cloud” and everyone seemed to have different ideas of what “the cloud” was or was talking about a different “cloud”. It’s called CloudLinux, people that have it call it cloud hosting, and so we’re just going with it and let it makes us feel all cutting edge.

Just go with it, folks – really. If you try and figure it out, it will just give you a headache. Trust us.