Conventions/vdomain: Difference between revisions
Jump to navigation
Jump to search
m (Woozle moved page Woozle/setups/vdomain to Setups/vdomain without leaving a redirect: "woozle" prefix not needed here) |
m (→File Structure: localized links) |
||
| Line 18: | Line 18: | ||
**** Repositories are directly under this, e.g. </code>{{arg|$HOME}}/site/git/ferreteria</code>. | **** Repositories are directly under this, e.g. </code>{{arg|$HOME}}/site/git/ferreteria</code>. | ||
**** Nothing in this folder should be edited, unless doing development on the repository itself. | **** Nothing in this folder should be edited, unless doing development on the repository itself. | ||
*** <code>/apps</code> for applications (e.g. MediaWiki) whose code is delivered via some method other than | *** <code>/apps</code> for applications (e.g. MediaWiki) whose code is delivered via some method other than {{l/htyp|git clone}} | ||
**** For Mediawiki specifically, where there are no other apps I've been just using <code>mw</code> instead of <code>apps/mw</code>. | |||
**** A lot of web apps mix together site-config files and read-only code files, so this folder may need to be writeable. | **** A lot of web apps mix together site-config files and read-only code files, so this folder may need to be writeable. | ||
** <code>/public_html</code> is {{arg|$WEB}}, i.e. files to be served on the web | ** <code>/public_html</code> is {{arg|$WEB}}, i.e. files to be served on the web | ||
*** Personally I'd prefer <code>/web</code> or <code>/www</code>, but this ↑ is | *** Personally I'd prefer <code>/web</code> or <code>/www</code>, but this ↑ is {{l/htyp|VirtualMin}}'s default | ||
Wherever possible, I will make links inside {{arg|$WEB}} to files/folders in <code>{{arg|$HOME}}/site</code> rather than copying them, in order to minimize scattering of edit-targets and simplify updates a bit. | Wherever possible, I will make links inside {{arg|$WEB}} to files/folders in <code>{{arg|$HOME}}/site</code> rather than copying them, in order to minimize scattering of edit-targets and simplify updates a bit. | ||
Revision as of 16:34, 23 October 2020
Virtual Domain Setup
This is how I typically set up virtual domains.
Definitions
- <$HOME> is the home folder of the virtual domain's user account
- e.g.
/home/wvbz/
- e.g.
- <$USER> is the system user that Apache will run as
- e.g.
wvbz
- e.g.
- <$WEB> is the base folder of files that will be served to the web
- Typically
<$HOME>/public_html - e.g.
/home/wvbz/public_html
- Typically
File Structure
<$HOME>- domain user's home folder/site- all site-specific stuff/config- any configuration stuff that might change- there's a folder for each project that has configurable files, typically in lowercase
- e.g.
<$HOME>/site/config/vbzcart
- e.g.
- there's a folder for each project that has configurable files, typically in lowercase
/git- Git repositories being used for this domain/project- Repositories are directly under this, e.g. <$HOME>/site/git/ferreteria.
- Nothing in this folder should be edited, unless doing development on the repository itself.
/appsfor applications (e.g. MediaWiki) whose code is delivered via some method other than git clone- For Mediawiki specifically, where there are no other apps I've been just using
mwinstead ofapps/mw. - A lot of web apps mix together site-config files and read-only code files, so this folder may need to be writeable.
- For Mediawiki specifically, where there are no other apps I've been just using
/public_htmlis <$WEB>, i.e. files to be served on the web- Personally I'd prefer
/webor/www, but this ↑ is VirtualMin's default
- Personally I'd prefer
Wherever possible, I will make links inside <$WEB> to files/folders in <$HOME>/site rather than copying them, in order to minimize scattering of edit-targets and simplify updates a bit.