diff options
author | Robin H. Johnson <robbat2@gentoo.org> | 2015-08-08 13:49:04 -0700 |
---|---|---|
committer | Robin H. Johnson <robbat2@gentoo.org> | 2015-08-08 17:38:18 -0700 |
commit | 56bd759df1d0c750a065b8c845e93d5dfa6b549d (patch) | |
tree | 3f91093cdb475e565ae857f1c5a7fd339e2d781e /www-apps/phpwebsite/files | |
download | gentoo-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.txt | 130 |
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. |