VMWare: Windows 2003 Host, CentOS 5 Guest – Bridged Networking
Oct0
We would usually just setup a NAT based VM appliance for any new requirement. Most of the time, access is limited to ones desktops. When the need arise for a shared Linux VM on our local Windows 2003 server, the inexperienced may find it trouble setting up the CentOS guest as a reachable application server just like its host OS.
To achieve this, make sure the following items a re true:
- HOST » VMWare » Edit » Virtual Network Editor
- Automatic Bridging - "Automatically choose an available physical network adapter to bridge to VMNet0" is UNCHECKED
- Host Virtual Network Mapping - VMNet0 is mapped to you chosen physical adapter, NOT automatically.
- You can disable NAT, DHCP and Host Virtual Network Adapters
- HOST » Control Panel » Network Connections
- Right click your chosen physical adapter, then Properties. Make sure "VMWare Bridge Protocol" is CHECKED.
- GUEST - Assign an unused static IP, the same network/netmask and gateway that is used on your host's physical adapter.
Other items worth checking when inbound and outbound connections from the guest OS:
- Host firewall
- Guest DNS server settings, resolv.conf.
This checklist should get you up and running with a virtualized development platform with the same network visibility as a physical machine in your office.
PCI Compliance
Oct0
It has not been long that I've become involved on many a client requests to make their servers PCI compliant. More often than not they would just pass onto us at least a 30 page report of what's needed to be done to become "PCI Compliant". This would often cause a short debacle between us and the clients since merely looking at the report and evaluating what is needed to be done on our part already costs our time.
The point of this article is how much should we get involved on getting our customers "PCI Compliant"?
From a customer's point of view, generally they would expect all the technical work necessary be done out of the report. From my point of view, this should not be the case. Security compliance is another box when it comes to web hosting, if the customers are employing a third party security company then they should do most of the leg work. We do not need to analyze pages of report that those security comapnies are supposed to be doing. We'd more than happy to get the customer compliant, but we only need the specific technical points to do our part. Yes, the customer gets confused at first when we throw back at them these ideas, fortunately they would get our point and point back to the security vendor then the vendor liasing directly back to us.
I'd hope there is a much more structured process between the security vendor, the customer and the hosting company. How about you, how have you been doing so far as a customer, vendor or a hosting company with your part on the PCI compliance process?
FFMpeg-PHP: undefined symbol: php_gd_gdImageSetPixel
Oct3
I was recently updating ffmpeg-php on one of our servers to the latest SVN release of the 0.6.3 branch. On a 64bit CentOS 5.3 with PHP 5.2.11, the extension compiled and installed fine however Apache will not load it and spit out the error below:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/ffmpeg.so' - /usr/lib64/php/modules/ffmpeg.so: undefined symbol: php_gd_gdImageSetPixel in Unknown on line 0
Surely enough, the GD extension was there, but why is ffmpeg complaining about not finding that shared symbol? Because, ffmpeg is loading first than GD (alphabetically) and such symbol has not been loaded. After adding the GD extension line on top of ffmpeg making sure it loads first the error went away and all is well again.