summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRobin H. Johnson <robbat2@gentoo.org>2015-08-08 13:49:04 -0700
committerRobin H. Johnson <robbat2@gentoo.org>2015-08-08 17:38:18 -0700
commit56bd759df1d0c750a065b8c845e93d5dfa6b549d (patch)
tree3f91093cdb475e565ae857f1c5a7fd339e2d781e /www-apps/phpwebsite/files
downloadgentoo-56bd759df1d0c750a065b8c845e93d5dfa6b549d.tar.gz
gentoo-56bd759df1d0c750a065b8c845e93d5dfa6b549d.tar.bz2
gentoo-56bd759df1d0c750a065b8c845e93d5dfa6b549d.zip
proj/gentoo: Initial commit
This commit represents a new era for Gentoo: Storing the gentoo-x86 tree in Git, as converted from CVS. This commit is the start of the NEW history. Any historical data is intended to be grafted onto this point. Creation process: 1. Take final CVS checkout snapshot 2. Remove ALL ChangeLog* files 3. Transform all Manifests to thin 4. Remove empty Manifests 5. Convert all stale $Header$/$Id$ CVS keywords to non-expanded Git $Id$ 5.1. Do not touch files with -kb/-ko keyword flags. Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> X-Thanks: Alec Warner <antarus@gentoo.org> - did the GSoC 2006 migration tests X-Thanks: Robin H. Johnson <robbat2@gentoo.org> - infra guy, herding this project X-Thanks: Nguyen Thai Ngoc Duy <pclouds@gentoo.org> - Former Gentoo developer, wrote Git features for the migration X-Thanks: Brian Harring <ferringb@gentoo.org> - wrote much python to improve cvs2svn X-Thanks: Rich Freeman <rich0@gentoo.org> - validation scripts X-Thanks: Patrick Lauer <patrick@gentoo.org> - Gentoo dev, running new 2014 work in migration X-Thanks: Michał Górny <mgorny@gentoo.org> - scripts, QA, nagging X-Thanks: All of other Gentoo developers - many ideas and lots of paint on the bikeshed
Diffstat (limited to 'www-apps/phpwebsite/files')
-rw-r--r--www-apps/phpwebsite/files/postinstall-en.txt130
1 files changed, 130 insertions, 0 deletions
diff --git a/www-apps/phpwebsite/files/postinstall-en.txt b/www-apps/phpwebsite/files/postinstall-en.txt
new file mode 100644
index 000000000000..7bca5583dafb
--- /dev/null
+++ b/www-apps/phpwebsite/files/postinstall-en.txt
@@ -0,0 +1,130 @@
+phpWebSite is installed.
+
+Installation Instructions
+=========================
+
+You will need to create a database for phpWebSite
+on your own before starting setup.
+
+Then change permissions for set with this script:
+
+cd ${MY_INSTALLDIR}/setup
+./secure_phpws.sh setup
+
+Once you have a database ready proceed to
+http://${VHOST_HOSTNAME}/${VHOST_APPDIR} to continue installation.
+
+Once you are done with installation you need to run:
+
+cd ${MY_INSTALLDIR}/setup
+./secure_phpws.sh run apache users
+
+Upgrade Instructions
+====================
+
+Preparing to Upgrade
+--------------------
+ - Dump/backup your hub and branch databases.
+ - Backup your hub and branch directories/files.
+ - Create an index.php file that warns users of the upgrade.
+
+<?php
+echo "<div align=\"center\"><h1>Please be patient while we upgrade the site.</h1>
+We'll be back in a jiffy!</div>";
+?>
+
+ - Close and restart your browser. If you have a session live while updating
+ your site, it MIGHT interfere with the upgrade process. If you are using
+ Boost to upgrade, you can skip this step.
+
+If you are upgrading to 0.9.3 or greater, you should make the images/
+directory and subdirectories writable by the web server.
+
+Prepare your branches if you are running any off of your hub site. Depending
+on the owner of these directories will affect the commands to run. The base
+directory of each branch will need to be writable.
+
+If the owner is the webserver and you have root access:
+chmod o+rwx branch1/
+chmod o+rwx branch2/
+etc...
+
+otherwise:
+chmod 0777 branch1/
+chmod 0777 branch2/
+etc...
+
+The images and themes directories will also need to be writable for the
+upgrade:
+
+chmod -R o+rwx branch1/{images,themes}
+chmod -R o+rwx branch2/{images,themes}
+
+-or-
+
+chmod -R 0777 branch1/{images,themes}
+chmod -R 0777 branch2/{images,themes}
+
+If the webserver is not given the proper permissions then the branch upgrade
+will not be successfull.
+
+
+Once you have you have finished these steps (and ONLY after) should you
+continue.
+
+Running the Upgrade
+--------------------------------------
+Now you can untar the new files into your installation. If you go to
+your site's index.php file, you will see a few error messages. The
+aforementioned index.php prevents most people from seeing these messages.
+Point your browser to 'http://www.myWebSitesName.com/setup/' where
+'www.myWebSitesName.com' is the address for your web site.
+
+The first thing the upgrader will do is upgrade your core modules. It
+will also check to see if you are running any branch sites and automatically
+upgrade them as well.
+
+You should receive a 'Core Updated!' message. Underneath these messages
+will be a list of modules that appear to need upgrading as well. Click
+the checkboxes of the modules you want updated (or click the 'Check All' button
+to check all of them) and click the 'Update Modules' button. Your site and
+all your branch sites should now be updated.
+
+If you made a warning index.php file, dump it and put the real file back.
+You should now be able to use your site as normal.
+
+Should something go wrong
+--------------------------------------
+If you go to your site and receive errors the FIRST thing you should try
+is closing your browser, reopening it, and trying to use your site again.
+Sometimes old sessions will conflict with the upgraded information.
+
+If you get an error message or your sites still don't function, restore your
+backed up databases and files and try again. If it STILL doesn't work, contact
+us via Sourceforge, we want to know what went wrong.
+
+Please include your OS, web server, PHP, and phpWebSite version information.
+Also include any error messages that were displayed. The more data you supply
+us, the better chance you will receive help.
+
+You may also try using the repair.php file. It contains answers to a few
+commonly experienced problems.
+
+Returning to update.php
+---------------------------------------
+Most of the time, Boost will handle your upgrade needs. However, should
+an upgraded module cause problems before you can get to the Boost module,
+you can always return to update.php to upgrade the offending module.
+
+Securing your Site
+---------------------------------------
+Although setup.php, update.php, and repair.php require passwords to enter,
+you may want to prevent malicious users (read: jerks) from even accessing
+these files. One way would be to limit read access on that directory after
+you are finished using it. Another measure would be to alter your
+allow_setup.php file. Open this file in an editor and change the 'TRUE'
+to 'FALSE' like so:
+
+$_SESSION['allow_setup'] = FALSE;
+
+Change this back to TRUE when you need to update again.