Joe Fortier's questions

Windows VMWare guests can easily be resized live. For linux guests I've used LVM (add disk, partprobe, add disk to vg, lvextend, resize2fs). This works.

I've just stumbled across the sketch of better approaches. The first seems eminently doable, use LVM physical volume without partitions. This allows extending with one extra volume (and significanly simpler and less work). It'd be even better if I could whittle it down to s single VMDK

The more tantilizing option though is hinted at in a couple of posts scattered about the internet (including the unix cousin of this sight) running off of a partitionless VMDK. This seems very clean, but I'm running into a major roadblock for testing (and implementation) installing to a partionless system.

We are a SLES/OES shop, this may well be easy with another distro, but I cannot get the installer to skip partitioning. I've tried presenting it with preformatted whole disk and various permutations of the SLES installation disk formatting process.

FWIW, here are some postings...

https://unix.stackexchange.com/questions/14010/the-merits-of-a-partitionless-filesystem (last post)

http://v-reality.info/2010/06/working-with-linux-volumes-n-vsphere/

I could manually copy/move things about. Does anyone have any suggestions?

I'm interested in comments and strategies for protecting PHP config files, particularly those with Db credentials.

The stock advice, set the file extension to *.php, is fine as far as it goes, but it does not protect against directory perusal attacks. The particular scenario I'm considering:

1. We have a server that hosts a variety of third party apps.
2. We cannot thoroughly vet all apps
3. If an attacker compromises an app, they can potentially use that app to read files from other directories. Db config files are an obvious target.

I have a solution, one that seems to have merit, but I'm not entirely comfortable with it. I'd love to hear comments on it, as well as

1. find what php_include is set to
2. place the config file in that directory
3. make sure the require/include statements that load the config do not specify hard path (no leading ./ etc.)

GOALS

• hides the config file completely from an errant sister web app (and more importantly from the webserver itself).

• obscures the actual location of the config file. It cannot easily be determined from reading the code. This is opposed to specifying a path outside of the web tree.

• minimal intervention, both on a server level and on an app level.

• Avoids hard coding the path.

This does not address config file name conflicts, although more then a few apps it's probably worth changing the include config file name.

Unfortunately a lot of our web apps appear to require hard coded paths.

What approaches have others come up with?