The ISP’s internet connection runs on port expecting a 10MB Full-duplex device to be plugged into it. The WAN interface on my pfSense box is a 10/100 NIC, which when uplinked without making any configuration changes, I found that I was only getting about 25% of the capacity I was expecting. The only way to force the WAN interface to 10MB/Full-duplex is via the /conf/config.xml file. There are two way to edit this… one is using vi from SSH.

To enable SSH do this from the PFSense web-interface:
Click System>Advanced>Secure Shell, Enable Secure Shell

Even if you prefer to use the PFSense web-interface to edit your config.xml file (make a backup copy first), the shell came in handy a few times throughout my configuration process. The other option to edit the config file is using the editor in the PFSense web-interface.

The editor is available here:
Diagnostics>Edit File. The Load/Save path is “/conf/config.xml”.

Scroll down until you find the tag. Then remove the lines that start with <media/> and <mediaopt/> and replace them with ones that say this:

<media>10baseT/UTP</media>
<mediaopt>full-duplex</mediaopt>

Then click Save. You can check to see if this took effect by clicking Status, Interfaces. The WAN interface should now read “10baseT/UTP ”. This change should take effect immediately – if not, give the box a reboot (Diagnostics>Reboot System).

Occasionally I’ve run into a VM that gets stuck at 95% while powering down (or during a vMotion).  I know the issue isn’t unheard of, but I didn’t run into it until working with a few ESXi 4.0.0 208167 servers. So – if you have a virtual machine hangs while shutting down – and you’re certain that you’re just not waiting for it to finish powering down, and you’ve already tried to “power off” from the client- but the power-off command is stuck at 95%, you may have to manually kill the hung VM.

1. Login to the host with the hung machine via SSH (enable SSH if you haven’t already)
2. do a /sbin/services.sh restart (or services vmware-mgmt restart on ESX)… which is the same thing as doing this from the ESXi console
3. This command will restart the agents that are installed in /etc/init.d/ … including hostd, ntpd, sfcbd, sfcbd-watchdog, slpd and wsmand (and HA if you have it)
4. When you do this, the VI/vsphere client will loose connectivity as those services restart, but VM’s that are running will not be affected
5. After the services have restarted, you can re-connect via the VI client.
6. Via SSH, go to the right datastore (such as, /vmfs/volumes/DatastoreName/VMname), and delete (rm -r) the *.vswp file (the swap file).
7. If you can’t delete it, and you’re getting an error message to the effect… can not remove VM: device or resource busy… go find the processes associated with the VM.
8. “ps auxfww|grep “vmname”
9. “kill -9 ProcessIDNumber”
10. After doing so, remove the orphaned VM from inventory… just right-click the “unknown” VM, and select “remove from inventory”, being careful to not delete it.
11. Then delete the *.log, and *.0*. If you don’t, re-adding the VM may cause the interface to hang, and you’ll have to go through some of this all over again.
12. Add the VM back to the inventory, and you should be able to start the VM.

I have run into a situation once, where a host reboot was the only way to solve the problem. But other than that, this seems to be quite effective.  The short version – see steps 8 & 9.

Back in the 90’s, before content management systems, Intranet sites, and WYSIWYG editors, web-sites were built by hand with HTML code and ASCII text editors.  Folks armed with a bit of knowledge and some patience, laboriously constructed web sites.  Even if you happened to use tools like the HotDog HTML editor, bringing web-sites to market was a time consuming and expensive endeavor.  Fortunately, that’s no longer the case.  We all know the story… web technologies, driven in no small part by the explosive growth of tablets, and smartphones, have advanced and we have a modern ecosystem that was barley hinted at in the 90s.  Underpinning much of the modern web, are content management systems (CMS) like WordPress, which enable and accelerate bringing web-sites and projects to market.

My goal with this series to essentially provide small & medium sized business with a WordPress Toolkit, arming you with everything you need to know to either bring a site to market yourself, or give you enough knowledge to make good decisions when it comes to hiring a company to partner with.

What is a Content Management System

There are probably some use cases where hand-coding web sites still makes sense.  For the rest of us, content management systems (CMS) exist to save us time, and money.  A CMS is a piece of software that manages web-site content.  Sounds simple, right?  By that definition there are hundreds of CMS platforms today, incorporating solutions as disparate as blogger.com and WordPress.  You could always choose a CMS platform and hosting option in one, putting your site on somewhere like blogger.com, or the like… but why would you opt for a free site (e.g. yousite.blogger.com), where your content is really only serving to increase the value, brand, and awareness of someone else’s property?  While you might choose to augment your business’s content via micro blogging and social media sites like Tumblr, Twitter, Facebook, Instagram, etc., your presence on those properties should serve to increase the brand and awareness of your business, and bring people to your web site.  Think in terms of your web-site as being the hub of your presence, and spokes extending out to other properties that serve to increase your exposure.

To filter down the number of CMS platforms a bit, when I talk about a CMS platform, what I’m really referring to is the mainstream open source options that are common on many hosting platforms.  The top three by marketshare are Joomla, Drupal, and WordPress.  Of those, WordPress accounts for roughly 75% of the CMS market, powering the infrastructure of more than 100 million web sites, including big sites that you’ve probably heard of like TechCrunch, CNN, TED, and others.

But what about… Joomla, and Drupal?

Both Joomla and Drupal are fine CMS platforms.  I’ve taken a look and kicked the tires a bit.  But here’s my biggest problem… I’ve only had one client ever even mention anything other than WordPress them by name.  For the clients that I work with, many have some sort of familiarity with WordPress, even if it’s just that they’ve heard of it before.  And then we talk about the fact that CNN, UPS, TechChurch, and so many other high-profile sites run WordPress… for many, using WordPress is a forgone conclusion.  Which isn’t to say that WordPress is without its faults, but it is an enabling platform that helps you bring your project online quickly without necessarily needing to dig into the code.

What are some of WordPress’s faults?

There’s plenty of naysayers out there for whatever your selection of a CMS platform turns out to be.  With that in mind, in the case of WordPress, the fact that it owns a significant portion of the market has to some extent, made it a victim of its own success.  Not unlike Microsoft’s Windows platform, or Google’s Android platform.  If you think about the economics involved it quickly becomes obvious, the biggest players in a market tend to be the one’s targeted for malware and virus exploits simply because there are large number of targets to exploit.  If I was going to identify the single biggest “problem” with WordPress – it’s that its marketshare makes it a bigger target.  That same market share is also why it gets the most developer attention and why it has the most robust plug-in ecosystem.  This isn’t to say that you’re better off with Joomla or Drupal – particularly if you don’t know much about those platforms, as each has its own vulnerabilities.  But what I am saying is that there’s a tradeoff.

Performance

Another area that you might find folks arguing against WordPress is performance.  Probably the biggest thing to keep in mind about performance is that…

1. For the vast majority of even mid-size organizations, WordPress performance isn’t something you really need to give much thought to.
2. If WordPress performance is a problem for you that
   probably means that you have enough visitors and traffic (and revenue) to deal with the problem.
3. If you’re a small site with a performance problem, your theme is probably the most likely reason.

In short though, for most folks, avoiding WordPress because of performance concerns just doesn’t hold water.  For organizations that do have real performance concerns, there are several ways to address that which we’ll touch-on elsewhere in this series.

My recommendation, of course is to go the WordPress route and make good decisions as you go.  And I’ll be here to help you make good decisions.

Forecasting utilization is the bane of every business where high-skill employees bill their time in hours.  For far too many companies, juggling individuals, teams, and clients isn’t just an occasional necessity… it’s the status quo.  And as you scale the business, what might have seemed easy with a small team, only gets harder the closer you get to your Dunbar number.  It seems like almost overnight, you’ve gone from making strategic decisions, to survival mode.  Instead of focusing on resource utilization, improving margins, and holding individuals and teams accountable, these suddenly seem like luxuries you can’t afford – even when you know that doing so is critical to your success.  To make matters worse, Project Managers who might be able to help drive this, are so busy with Project schedules, or trying to come up with an S-curve that they’re unable to contribute in a meaningful way to solving this problem.

But what if there was a better way to do forecasting in a small business?  What if you could drive accountability across a growing organization, eliminate choke-points, enable you to scale the business, and at the same time reduce the number of unknowns?

That’s why I developed Iceberg.

Iceberg turns traditional top-down forecasting on its head.  Instead of relying of Project Managers, or individuals in “leadership” positions to forcast top-down, Iceberg makes it painless for everyone to forecast their own utilization, letting you understand what’s going on beneath the surface of your business.  Three months after implementing Iceberg…

• Forecast Accuracy improved by 25%
• Service revenue increased by 15% 
• The number of bad surprises were cut in half!
• Leadership began to focus on strategic decisions instead of fighting fires 

Iceberg is available for purchase directly (contact me), and I’m also considering making it available as an SaaS application if there’s sufficient interest – please fill out the survey form.

Watch the beta intro and demo.