AgileApps Support Wiki Pre Release

Difference between revisions of "User:Aeric/Configuration"

From AgileApps Support Wiki
imported>Aeric
(Created page with "<noinclude>__TOC__</noinclude> ===How the Wiki Works=== :* Mediawiki consists of a database and a bunch of PHP scripts and supporting files in the Wiki directory. :* The actual W…")
 
imported>Aeric
m (Text replace - 'agileappslive' to 'agileappscloud')
 
(55 intermediate revisions by the same user not shown)
Line 1: Line 1:
<noinclude>__TOC__</noinclude>
<noinclude>__TOC__</noinclude>
===How the Wiki Works===
===Configuration Notes===
:* Mediawiki consists of a database and a bunch of PHP scripts and supporting files in the Wiki directory.
:* The wiki is hosted at Rackspace.  
:* The actual Wiki content is contained in a database.  
:* The server can be accessed with a VPN connection, using either FTP or SSH.
:* Together, the file set and the database make up the Wiki that user sees.
:: FTP gives access to all of the Wiki files, which is generally sufficient.
:* In addition to PHP scripts, the directory contains:
:: (Access details are in emails.)
:*;LocalSettings.php: The master control script where everything else is configured.
:* DNS entries that point to the server are <tt>agileappscloud.info</tt> and <tt>platformatyourservice.com</tt>.
:*;skins/: The images and CSS files that create the "wrapper context" (headers, nav pane, etc.) for the wiki content.
:* Location of any given wiki is /usr/share/mediawiki/{wikiName}
:*;extensions/: MediaWiki plug-ins that have been downloaded and "installed" by referencing them in <tt>LocalSettings.php</tt>. (Since pages are loaded dynamically, once the extension is present, it is automatically part of the Wiki. No restart needed.)
:* Multiple subdomains are set up using Apache, the DNS server, and <tt>LocalSettings.php</tt>.  
:*;images/: A directory hierarchy that contains the image files after they have been loaded. The Wiki stores them there when you load an image, and keeps a pointer to them in the database.  
:* The DNS entries determine which subdomains are known to the world.
:*;image-files/: A directory we create on the local file system. It contains images that will be (or have been) uploaded to the wiki. The Wiki doesn't know about this directory. It's just a place where images can be saved before uploading. The backup system re-creates this directory from the <tt>images/</tt> file, so that an entire working environment is restored.
:* The wiki name in the url determines which wiki is accessed. (E.g. <tt>/wiki</tt>)
:*;download/: A directory we added to hold files we want to reference in the wiki. Only image files can be loaded into the Wiki. But that's ok. Image loads are done painfully, one at a time. Files in the <tt>download/</tt> folder can be easily updated en mass. (Image files need to be uploaded, so that "links" to them coded in the wiki cause the image to be displayed, rather than link text.)
:* The <tt>LocalSettings.php</tt> file in that wiki uses the subdomain to determine which skin is used.
:* The skin determines which logo is shown, which platform name to use, and the settings for several other variables, including the site name.


===How Links to the Wiki Work===
;Organization of the mediawiki.conf Configuration File:
(This is the email I sent to explain things for version 7.1.)
:* There are two <tt><VirtualHost></tt> sections, one for each virtual server:<br>(<tt>agileappscloud.info</tt> and <tt>platformatservice.com</tt>).


;Current Version Links:
:* Inside each virtual host, there is a <tt><Directory></tt> section for each wiki that can be accessed, as well as an <tt>Alias</tt> setting that maps the <tt>{domain}/xyz</tt> URL to the <tt>/usr/share/mediawiki/xyz</tt> wiki folder.
:As of today and going forward, these URLS will always point to the latest released version of the Support Wiki:
::  http://lj.platformatyourservice.com/wiki 
::  http://rn.platformatyourservice.com/wiki 
::  http://isv.platformatyourservice.com/wiki  


::(To get to the main pages, /wiki” isn’t needed.)
:* In the AgileAppsLive domain, the "/wiki" alias points to the <tt>aawiki</tt> wiki, as does the "/aawiki" alias.


:Those are the best links to send to current customers, as they’ll always point to the latest pages.  And they will always stay at the top of the Google search rankings, by virtue of being the most heavily accessed Wiki pages.
:* When <tt>scripts/versionProductionWiki</tt> is run to make a versioned copy of the production wiki, a new directory-section and alias are created for it. E.g. "aa90".


:Versioned links in bookmarks and emails will also work:
:* Each <tt><Directory></tt> contains a number of URL rewrites that are needed to make the wiki work properly. Unfortunately, they need to be copied for each directory.
::   http://lj.platformatyourservice.com/lj71 
::* Attempts to do global rewrites failed, as recorded in notes at the top of the file. However, the rewrites were ''not'' attempted inside the <tt><VirtualHost></tt> headings, as those came later.  
::   http://rn.platformatyourservice.com/lj71 
::* So it is possible that a clever configuration could cut down the size of the <tt><Directory></tt> segments.  
::   http://isv.platformatyourservice.com/lj71 
::* But, as the notes in the file attest, the Apache rewrites frequently do not work as documented--so the actual semantics must be discovered by trial and error. (A rainy day project for sure, not worth the time given that we have a working system.)


:Those links will be automatically forwarded to the /wiki pages for as long as 7.1 is current.
===Configuring Apache===
:But once 7.1 is no longer current, those links will go to the 7.1 version, not the latest version.
:* The Apache configuration file is <tt>/etc/httpd/conf.d/mediawiki.conf</tt>.


;Pre-Release Links:
:* Always preserve the original and edit a copy in <tt>/usr/share/mediawiki/apache_config</tt>
:Customers who need pre-release information can get it using links like these:
::  http://lj.platformatyourservice.com/lj72
::  http://rn.platformatyourservice.com/lj72
::  http://isv.platformatyourservice.com/lj72


:When version 7.2 is released, those links will be automatically redirected to the /wiki pages.
:* To edit, either:
:When 7.3 goes live, those links will once again point to the (now old) 7.2 pages.
::# SSH to the server using PuTTY or the SSH shell, and use a line-oriented editor like nano.
::# Use FTP to bring the file back to your workstation, and use a terrific editor like NotePad++


;Old Version Links:
===Maintenance Scripts===
:Anyone who needs to reference prior-release information can use links like these:
To use these scripts:
:  http://lj.platformatyourservice.com/lj70
# Using PuTTY, log in to Rackspace
:  http://rn.platformatyourservice.com/lj70
# <tt>cd /usr/share/mediawiki/apache_config</tt>
:  http://isv.platformatyourservice.com/lj70


===Wiki/Server Configuration Notes===
Scripts:
:* The wiki is hosted at Siteground. The site name is "platformatyourservice.com".
:* <tt>./get_conf</tt>
:: Gets a copy of the three main configuration files, primarily for backup:
::: <tt>httpd.conf</tt>
::: <tt>phpMyAdmin.conf</tt>
::: <tt>mediawiki.conf</tt>


:* Three subdomains are set up at there:  
:* <tt>./try_setup</tt>
:**  isv.platformatyourservice.com - for ISV users
:: Copies the current config file as <tt>mediawiki.conf_sav</tt>.
:**  lj.platformatyourservice.com  - for LongJump platform users
:: If no else is editing mediawiki.conf, then <tt>mediawiki.conf_new</tt> has the same content, and is ready to be edited. Otherwise, copy <tt>_sav</tt> to <tt>_new</tt> before you begin.
:**  rn.platformatyourservice.com  - for Relationals users


:* The DNS server forwards platformatyourservice.com -> isv.platformatyourservice
:* <tt>./try</tt>
:: Put <tt>mediawiki.conf_new</tt> in place and restart the server.
:: For a quick test, refresh the page for each of the main wikis:
:::* http://agileappscloud.info/wiki
:::* http://agileappscloud.info/aadev
:::* http://lj.platformatyourservice.com/wiki
:: If you can see the page and the generated links are correct, the wiki is usable.
:: If you've done any work on the skins, then test the changes, as well


:* The root directory for all three domains is <tt>/home/platfor1/public_host</tt> (aka <tt>~platfor1/public_host</tt>)
:* <tt>./revert</tt>
:* The Wiki examines the server name (which includes the subdomain) to determine which logos to show and which platform name to use:
:: Put <tt>mediawiki.conf_sav</tt> back in place, in case the _new version didn't work.
:** In <tt>{wiki_name}/LocalSettings.php</tt>, <tt>$wgSitename</tt> declares the name of the Wiki site.
:** That value is set conditionally, based on the hostname used to access the PHP page (lj.platformatyourservice.com or isv.platformatyourservice.com).
:** So the same verison of the Wiki is launched in all three cases, but LocalSettings.php changes <tt>$wgSitename</tt> depending on the subdomain used to access it (<tt>lj.platformatyourservice</tt> or <tt>isv.platformatyourservice</tt>).
:** When that variable's value is "ISV Support Wiki", the unbranded, ISV version of the wiki pages are shown. Otherwise, the LongJump logo and platform name appears.


:* In the root directory, <tt>/www</tt> is a symlink to <tt>~platfor1/public_host</tt>. That symlink makes FTP uploads easier. (It may also be served up by Apache. Not yet known.)
;Apache References:
:* The current (most recently released) version of the wiki is in <tt>public_host/wiki</tt>.
:* In the <tt>/public_host</tt> root directory, there is a PHP redirect file (<tt>index.php</tt>) that takes people who land there to the <tt>/wiki</tt> directory.
:* If the current version is 7.1, then <tt>public_host/lj71/</tt> contains a copy of that redirect file. So:
:**  When 7.1 is pre-release, bookmarks and email links can go directly to http://lj.platformatyourservice.com/lj71.
:**  After release, the links still work. (The release process will cause them redirected to the <tt>/wiki</tt> pages. BUT... All links from within the wiki go to <tt>/wiki</tt>--so users and the support crew will always have the latest released version in <tt>/wiki</tt>. (As Uday put it: "Wiki" is Sticky.)
:**  When 7.2 is released, <tt>/lj71</tt> will be restored, so any link that specifically went to that version will work, while any <tt>/wiki</tt> links will now go to the 7.2 version
 
===Accessing the Server===
The server can be accessed with a VPN connection, using either FTP or SSH.
FTP gives access to all of the Wiki files, which is generally sufficient.
(Details in emails.)
 
====Apache Modifications====
To modify the Apache configuration in /etc/httpd/conf.d/mediawiki.conf,
either:
# SSH to the server using PuTTY or the SSH shell, and use a line-oriented editor like nano.
# Set up [http://www.vanemery.com/Linux/VNC/vnc-over-ssh.html TightVnc] and use it to run a darn good editor like [http://www.nedit.org/features.php Nedit].
 
====Apache References====
:* http://net.tutsplus.com/tutorials/other/a-deeper-look-at-mod_rewrite-for-apache/
:* http://net.tutsplus.com/tutorials/other/a-deeper-look-at-mod_rewrite-for-apache/
:* http://www.addedbytes.com/download/regular-expressions-cheat-sheet-v2/png
:* http://www.addedbytes.com/download/regular-expressions-cheat-sheet-v2/png
:* http://www.addedbytes.com/cheat-sheets/mod_rewrite-cheat-sheet/
:* http://www.addedbytes.com/cheat-sheets/mod_rewrite-cheat-sheet/
===Backup Notes===
:* A MediaWiki site contains a number of ''wiki files'' and a ''database''.
:* The ''Wiki content files'' are in the <tt>images/</tt>, <tt>extensions/</tt>, and <tt>download/</tt> folders, plus some other files.
:* Each Wiki has its own database.<br/>The database contains page contents and edit history. It is created when the wiki is set up. It's actual location at Siteground is unclear, but we can export data from it using <tt>mysqldump</tt> and import data into it using <tt>mysql</tt>.
:* The <tt>/public_host/dbbackup</tt> folder contains database backups.<br/>(Each one is large. If there are many of them, they take up a lot of space on the server. There, they make it possible to go incrementally back in time, if needed. But the number of files needs to be trimmed to a reasonable level, from time to time.)
===Branching Notes===
:* The ''sandbox'' is the new wiki you are creating. There is (or will be) a local copy on your system, as well as the remote copy on the server.

Latest revision as of 23:56, 14 August 2015

Configuration Notes

  • The wiki is hosted at Rackspace.
  • The server can be accessed with a VPN connection, using either FTP or SSH.
FTP gives access to all of the Wiki files, which is generally sufficient.
(Access details are in emails.)
  • DNS entries that point to the server are agileappscloud.info and platformatyourservice.com.
  • Location of any given wiki is /usr/share/mediawiki/{wikiName}
  • Multiple subdomains are set up using Apache, the DNS server, and LocalSettings.php.
  • The DNS entries determine which subdomains are known to the world.
  • The wiki name in the url determines which wiki is accessed. (E.g. /wiki)
  • The LocalSettings.php file in that wiki uses the subdomain to determine which skin is used.
  • The skin determines which logo is shown, which platform name to use, and the settings for several other variables, including the site name.
Organization of the mediawiki.conf Configuration File
  • There are two <VirtualHost> sections, one for each virtual server:
    (agileappscloud.info and platformatservice.com).
  • Inside each virtual host, there is a <Directory> section for each wiki that can be accessed, as well as an Alias setting that maps the {domain}/xyz URL to the /usr/share/mediawiki/xyz wiki folder.
  • In the AgileAppsLive domain, the "/wiki" alias points to the aawiki wiki, as does the "/aawiki" alias.
  • When scripts/versionProductionWiki is run to make a versioned copy of the production wiki, a new directory-section and alias are created for it. E.g. "aa90".
  • Each <Directory> contains a number of URL rewrites that are needed to make the wiki work properly. Unfortunately, they need to be copied for each directory.
  • Attempts to do global rewrites failed, as recorded in notes at the top of the file. However, the rewrites were not attempted inside the <VirtualHost> headings, as those came later.
  • So it is possible that a clever configuration could cut down the size of the <Directory> segments.
  • But, as the notes in the file attest, the Apache rewrites frequently do not work as documented--so the actual semantics must be discovered by trial and error. (A rainy day project for sure, not worth the time given that we have a working system.)

Configuring Apache

  • The Apache configuration file is /etc/httpd/conf.d/mediawiki.conf.
  • Always preserve the original and edit a copy in /usr/share/mediawiki/apache_config
  • To edit, either:
  1. SSH to the server using PuTTY or the SSH shell, and use a line-oriented editor like nano.
  2. Use FTP to bring the file back to your workstation, and use a terrific editor like NotePad++

Maintenance Scripts

To use these scripts:

  1. Using PuTTY, log in to Rackspace
  2. cd /usr/share/mediawiki/apache_config

Scripts:

  • ./get_conf
Gets a copy of the three main configuration files, primarily for backup:
httpd.conf
phpMyAdmin.conf
mediawiki.conf
  • ./try_setup
Copies the current config file as mediawiki.conf_sav.
If no else is editing mediawiki.conf, then mediawiki.conf_new has the same content, and is ready to be edited. Otherwise, copy _sav to _new before you begin.
  • ./try
Put mediawiki.conf_new in place and restart the server.
For a quick test, refresh the page for each of the main wikis:
If you can see the page and the generated links are correct, the wiki is usable.
If you've done any work on the skins, then test the changes, as well
  • ./revert
Put mediawiki.conf_sav back in place, in case the _new version didn't work.
Apache References