Matt, the PCI regulations require from a hoster just a contractual confirmation, that he is AWARE of the regulations and KNOWS about the standards. Nothing more, nothing less..
The full responsibility has to be taken by the merchant as he is the only one who has a contract with a member (acquirer) or an IPSP.
The merchant is the one who has to care about compliance to the PCI standards (that includes his technology and his internal structures and operational procedures)
see: https://www.pcisecuritystandards.org/saq/index.shtml

These regulations postulate the use of firewalls to separate "functional" devices from each other. That means a firewall towards the open-network is not enough as you have to keep webserver, appl.server, database etc. apart from each other. It therefore does not make sense to put your client's processes on their "in-store" machine. You are free to use what you want but you better work with DMZ and IP tables or some free firewall apps and tune it well. Otherwise invalid settings will be detected in the vulnerability scan.

What you call "current PCI-safe" payment options is any solution from a PSP (Payment Service Provider) -and I mean only those who are listed as "PCI-compliant Service providers" in the VISA & MasterCard listings- that redirects the cardholder to a PCI compliant data entry form that the PSP provides. Usually those solutions are called Web payment frontends or html redirect forms.
Just check the listings of the associations to find a suitable solution. Just take care that they provide 3D-secure also.

Another Option is the integration of a compliant PA (Payment application). You find Providers of such solutions on the association websites too. Depending on the region the merchant is located in (US, LATAM, EMEA, ASIAPAC etc.) such PA has to pass a PA-DSS certification or not.
(e.g.: for US this is mandatory, but for EMEA and LATAM it is not.)

These two Options are the only way to get around any of the PCI regulations by a merchant.

The standard does not regard DRUPAL or UberCart as a PA but as a storefront.
Storefronts do not require "PA-DSS" nor "service provider DSS" certification. But if you develop a plugin or aplication for the storefront that manages Credit Card Payments, this will be seen as a PA and you might be forced to pass a DSS certification. (see the requirements on https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml)

Most important is awareness. If you do not instruct your client well, he might be in deep trouble. MasterCard does not take prisoners, they execute!!
I know dozens of cases where MasterCard imposed violation fees over 50.000 USD and more to mid-sized merchants who did not even know about PCI but have been compromised through data loss and ID theft. (internal and external)

So PCI really makes it easy:
a) integrate an existing and compliant PA or Service Provider OR
b) create your own PA and have it certified OR
c) make your client FULLY PCI compliant according the specifications OR
d) tell your client not to accept Cards any more

@ Ryan:
regarding your comment: "Looking over the docs once more, it reads to me to be referring to protecting your personal internet traffic with a firewall. This would mean your home or your office network. I can't imagine a web host wouldn't be operating behind a firewall, but maybe I'm misunderstanding something. "

-Yep, you misunderstood it.
The firewall has to protect your private / corporate network on one hand, but your webshop and the payment interface for sure too.
PCI wants a merchant to protect ANY PC of his employees with a (personal) firewall and anti-Virus software AND any of his applications connected to an open network like the internet.

@fourcws:
your are wrong regarding CVV/CVC2. There is NO PERMISSION AT ALL!!!! to store that value. Neither on a POS device nor in any ecommerce application. The same is with full magstripe data and PIN values.
Automated recurrent billing is always possible, if the transaction is flagged correctly. (that is depending on the abilities of your PSP / acxquirer / processor. Good ones can, others can't.. )
You see that in the native terminal protocol languages like ISO8583 and its dialects or APACS. Depending on the naming you find indicators for installemts or recurring billing.

Hope that helped a bit..