3

i looking at trying to make my web server easier to manage, backup and replicate. I have websites, config files, ssl certs, vhosts scattered all over the place. It seems logical that they should all be in one place. i was thinking of creating a directory in root like so

/data

and inside this have all the directories for my data on this webserver like so:

/data 
    /websites                    [websites directories]
    /ssl_certs                   [secure certificates for sites]
    /vhosts                      [virtual host files for sites]
    /config                      [Software config files (apache, mod_security etc.)
        /apache2                 [Apache Server Config files]
        /proftpd                 [FTP Server Config files]
    /utilities                   [Misc Bash Scripts]

this would mean if i had to replicate this server, i could install and config the required packages and then copy this folder across which will contain all of my data. Also i could backup everything on my server easily and quickly so in the event of needing to restore i would have all my data in one place.

so i have 3 questions:

is this a good idea or would it be more hassle than its worth?

would there be any security implications of doing things this way?

what is the standard way of doing this if the above is not feasible?

ewwhite
  • 194,921
  • 91
  • 434
  • 799
Michael Barrett
  • 135
  • 1
  • 1
  • 4

4 Answers4

3

I have something like this:

  • /etc/
    • apache2/
      • sites-available/
      • sites-enabled/
    • ssl/
      • *.crt
      • private/
        • *.key
  • /srv/
    • www/
      • $site/
        • htdocs/
        • logs/
        • cgi-bin/
ptman
  • 27,124
  • 2
  • 26
  • 45
  • 2
    kudos for using `/srv/` it is the location that the FSH standard and the gods want server specific data to reside. – pfo Jan 09 '12 at 12:41
2

Different sites do different things; if you have a backup system in place and disaster recovery plan that is thoroughly documented, and your config files are properly set up, where you put the files won't matter.

"Standards"...there's so many of them that it's a stupid name. There are typical sites but even that varies by distro and web server.

In the end, if you have it properly documented and backed up, this shouldn't be a problem. Do what fits best with your business/workflow and don't worry about it.

Bart Silverstrim
  • 31,092
  • 9
  • 65
  • 87
1

Typically configs go in /etc/appname (so certs are in /etc/nginx/certs/, passwords are /etc/nginx/passwords, individual vhost configs are in /etc/nginx/sites/, etc). This is not considered to be messy or 'all over the place'; everything is within the /etc/nginx/ dir.

The contents of the sites typically go in go in /var/www/site1, /var/www/site2, but this is configured on a per-site basis, and does not need to conform to this convention. (Each site could be in a radically different place if you choose, so long as the httpd has access.)

Note: I typically use nginx, but the config directory for apache should be /etc/apache2/. The same sentiment applies.

Note: it is another common convention to use /etc/apache2/sites-enabled/ and sites-available/, but I personally dislike that approach.

gWaldo
  • 11,887
  • 8
  • 41
  • 68
0

Unlike the other respondents I think there's a strong case for not using the default file layout - just as there are very good reasons for not using the default permissions model.

The issue I have with what you propose is that you've called the directory 'data' - I'd want to keep all the config and the SSL certs well separated from the content. And since the default config will mostly be /etc anyway, that seems like the logical place to leave it.

Where you may run into problems is where you add packages which will make changes to the config (e.g. adding apache modules). Intelligent use of directory softlinks can help with this.

symcbean
  • 19,931
  • 1
  • 29
  • 49