Cerb

Introduction If you installed Cerb from GitHub using Git then the process of updating to a new version is simple and straightforward. If you're using Subversion, you can switch to Git with these instructions. You won't need to copy your ... [More] framework.config.php or storage directories. Everything will be upgraded in place. Check your license expiration First, verify that your license is valid for the latest version. Navigate to Setup->Settings->License in Cerb. Check the date for Software Updates Expire: If it's in the future, you're all set. Continue to the next section. If it's in the past, you either need to renew your license or upgrade to the latest version covered by your license. You can check approximate release dates from our profile on Freecode. Make a backup Refer to the instructions here to make a recent backup: http://cerbweb.com/book/latest/admin_guide/backups/ Updating the project files We recommend creating a new branch for each version of the project. With a branch per version you can make an informed decision about which of your modifications and hacks to carry over. Some of your modifications to the project files may not make sense in the latest version because your feedback was implemented. You're perfectly welcome to modify the main project files, but the officially recommended way to extend the software is to take advantage of our comprehensive plugin system. Using plugins, your changes will be easily portable between versions or environments. Let's proceed with the upgrade by creating a new version branch: Open a console on your server and change to the directory of your Cerb installation. First, you'll want to stash your local changes to files like framework.config.php, which will make merging changes easier: git stash Find the name of the remote repository. In most cases this will be origin by default. You can verify this with: git remote Fetch the branches from the remote server: git fetch origin From here you can decide which version to upgrade to: git branch -r Add a new local branch for the desired version: git branch --track 6.7 origin/6.7 Switch to the new version branch: git checkout 6.7 Re-apply your local stashed changes: git stash pop Note: If you'd prefer to use a single branch instead of one branch per version, you can use the stable branch instead of a version number. This branch will always contain the files for the most recent release, but you may have to manually merge conflicts if you've made changes to the code. In the event of conflicts... If your stashed changes were non-trivial then you may run into a situation where your changes conflict with our changes in the new version. In such a situation you can decide to merge the changes by hand, using a command like git mergetool, or you can simply reset such files to their default state with git checkout -- <file> Permissions It is possible that using version control systems like Git and Subversion will modify your file permissions. You should verify that all files are owned and readable by your webserver user, and that the /storage directory and its contents are owned and readable+writeable by your webserver user. Upgrading the database Once your files are updated to a new version, Cerb automatically brings your database up to date and migrates any relevant data to new formats. For a major upgrade there will almost always be changes to the database. This section may not apply for smaller maintenance updates. To start the database upgrade process you simply need to navigate to your helpdesk using a browser. You can also initiate this process manually by opening the /update page. For example, if your helpdesk is located at http://example.com/cerb/ then you would open http://example.com/cerb/update in your browser. Note: If you aren't using friendly URLs, then you would navigate to http://example.com/cerb/index.php/update instead. Once the database is upgraded then you'll be returned to your login form and you can resume using the helpdesk. Purge the /install directory Make sure the /install directory is deleted. It is possible for version control systems like Git to restore this directory during an upgrade. Updating Community Portals If you have Community Portals in use, like the Support Center, then it's a good idea to make sure they're using the latest version of the deployed index.php file. This file rarely changes, but you will experience subtle and difficult to diagnose problems if it does change and you don't update your portals. Navigate to Setup->Community Portals->Configure. For each Community Portal, click on it and open the Installation tab. Copy the contents of index.php to the location where your portal is installed. All done! You should be all set to take advantage of our latest improvements. Be sure to review the list of changes for the new version. [Less]

Introduction If you installed Cerb from GitHub using Git then the process of updating to a new version is simple and straightforward. If you're using Subversion, you can switch to Git with these instructions. You won't need to copy your ... [More] framework.config.php or storage directories. Everything will be upgraded in place. Check your license expiration First, verify that your license is valid for the latest version. Navigate to Setup->Settings->License in Cerb. Check the date for Software Updates Expire: If it's in the future, you're all set. Continue to the next section. If it's in the past, you either need to renew your license or upgrade to the latest version covered by your license. You can check approximate release dates from our profile on Freecode. Make a backup Refer to the instructions here to make a recent backup: http://cerbweb.com/book/latest/admin_guide/backups/ Updating the project files We recommend creating a new branch for each version of the project. With a branch per version you can make an informed decision about which of your modifications and hacks to carry over. Some of your modifications to the project files may not make sense in the latest version because your feedback was implemented. You're perfectly welcome to modify the main project files, but the officially recommended way to extend the software is to take advantage of our comprehensive plugin system. Using plugins, your changes will be easily portable between versions or environments. Let's proceed with the upgrade by creating a new version branch: Open a console on your server and change to the directory of your Cerb installation. First, you'll want to stash your local changes to files like framework.config.php, which will make merging changes easier: git stash Find the name of the remote repository. In most cases this will be origin by default. You can verify this with: git remote Fetch the branches from the remote server: git fetch origin From here you can decide which version to upgrade to: git branch -r Add a new local branch for the desired version: git branch --track 6.7 origin/6.7 Switch to the new version branch: git checkout 6.7 Re-apply your local stashed changes: git stash pop Note: If you'd prefer to use a single branch instead of one branch per version, you can use the stable branch instead of a version number. This branch will always contain the files for the most recent release, but you may have to manually merge conflicts if you've made changes to the code. In the event of conflicts... If your stashed changes were non-trivial then you may run into a situation where your changes conflict with our changes in the new version. In such a situation you can decide to merge the changes by hand, using a command like git mergetool, or you can simply reset such files to their default state with git checkout -- Permissions It is possible that using version control systems like Git and Subversion will modify your file permissions. You should verify that all files are owned and readable by your webserver user, and that the /storage directory and its contents are owned and readable+writeable by your webserver user. Upgrading the database Once your files are updated to a new version, Cerb automatically brings your database up to date and migrates any relevant data to new formats. For a major upgrade there will almost always be changes to the database. This section may not apply for smaller maintenance updates. To start the database upgrade process you simply need to navigate to your helpdesk using a browser. You can also initiate this process manually by opening the /update page. For example, if your helpdesk is located at http://example.com/cerb/ then you would open http://example.com/cerb/update in your browser. Note: If you aren't using friendly URLs, then you would navigate to http://example.com/cerb/index.php/update instead. Once the database is upgraded then you'll be returned to your login form and you can resume using the helpdesk. Purge the /install directory Make sure the /install directory is deleted. It is possible for version control systems like Git to restore this directory during an upgrade. Updating Community Portals If you have Community Portals in use, like the Support Center, then it's a good idea to make sure they're using the latest version of the deployed index.php file. This file rarely changes, but you will experience subtle and difficult to diagnose problems if it does change and you don't update your portals. Navigate to Setup->Community Portals->Configure. For each Community Portal, click on it and open the Installation tab. Copy the contents of index.php to the location where your portal is installed. All done! You should be all set to take advantage of our latest improvements. Be sure to review the list of changes for the new version. [Less]

Introduction If you installed Cerb from GitHub using Git then the process of updating to a new version is simple and straightforward. If you're using Subversion, you can switch to Git with these instructions. You won't need to copy your ... [More] framework.config.php or storage directories. Everything will be upgraded in place. Check your license expiration First, verify that your license is valid for the latest version. Navigate to Setup->Settings->License in Cerb. Check the date for Software Updates Expire: If it's in the future, you're all set. Continue to the next section. If it's in the past, you either need to renew your license or upgrade to the latest version covered by your license. You can check approximate release dates from our profile on Freecode. Make a backup Refer to the instructions here to make a recent backup: http://cerbweb.com/book/latest/admin_guide/backups/ Updating the project files We recommend creating a new branch for each version of the project. With a branch per version you can make an informed decision about which of your modifications and hacks to carry over. Some of your modifications to the project files may not make sense in the latest version because your feedback was implemented. You're perfectly welcome to modify the main project files, but the officially recommended way to extend the software is to take advantage of our comprehensive plugin system. Using plugins, your changes will be easily portable between versions or environments. Let's proceed with the upgrade by creating a new version branch: Open a console on your server and change to the directory of your Cerb installation. First, you'll want to stash your local changes to files like framework.config.php, which will make merging changes easier: git stash Find the name of the remote repository. In most cases this will be origin by default. You can verify this with: git remote Fetch the branches from the remote server: git fetch origin From here you can decide which version to upgrade to: git branch -r Add a new local branch for the desired version: git branch --track 6.7 origin/6.7 Switch to the new version branch: git checkout 6.7 Re-apply your local stashed changes: git stash pop Note: If you'd prefer to use a single branch instead of one branch per version, you can use the stable branch instead of a version number. This branch will always contain the files for the most recent release, but you may have to manually merge conflicts if you've made changes to the code. In the event of conflicts... If your stashed changes were non-trivial then you may run into a situation where your changes conflict with our changes in the new version. In such a situation you can decide to merge the changes by hand, using a command like git mergetool, or you can simply reset such files to their default state with git checkout -- <file> Permissions It is possible that using version control systems like Git and Subversion will modify your file permissions. You should verify that all files are owned and readable by your webserver user, and that the /storage directory and its contents are owned and readable+writeable by your webserver user. Upgrading the database Once your files are updated to a new version, Cerb automatically brings your database up to date and migrates any relevant data to new formats. For a major upgrade there will almost always be changes to the database. This section may not apply for smaller maintenance updates. To start the database upgrade process you simply need to navigate to your helpdesk using a browser. You can also initiate this process manually by opening the /update page. For example, if your helpdesk is located at http://example.com/cerb/ then you would open http://example.com/cerb/update in your browser. Note: If you aren't using friendly URLs, then you would navigate to http://example.com/cerb/index.php/update instead. Once the database is upgraded then you'll be returned to your login form and you can resume using the helpdesk. Purge the /install directory Make sure the /install directory is deleted. It is possible for version control systems like Git to restore this directory during an upgrade. Updating Community Portals If you have Community Portals in use, like the Support Center, then it's a good idea to make sure they're using the latest version of the deployed index.php file. This file rarely changes, but you will experience subtle and difficult to diagnose problems if it does change and you don't update your portals. Navigate to Setup->Community Portals->Configure. For each Community Portal, click on it and open the Installation tab. Copy the contents of index.php to the location where your portal is installed. All done! You should be all set to take advantage of our latest improvements. Be sure to review the list of changes for the new version. [Less]

Introduction If you installed Cerb from GitHub using Git then the process of updating to a new version is simple and straightforward. If you're using Subversion, you can switch to Git with these instructions. You won't need to copy your ... [More] framework.config.php or storage directories. Everything will be upgraded in place. Check your license expiration First, verify that your license is valid for the latest version. Navigate to Setup->Settings->License in Cerb. Check the date for Software Updates Expire: If it's in the future, you're all set. Continue to the next section. If it's in the past, you either need to renew your license or upgrade to the latest version covered by your license. You can check approximate release dates from our profile on Freecode. Make a backup Refer to the instructions here to make a recent backup: http://cerbweb.com/book/latest/admin_guide/backups/ Updating the project files We recommend creating a new branch for each version of the project. With a branch per version you can make an informed decision about which of your modifications and hacks to carry over. Some of your modifications to the project files may not make sense in the latest version because your feedback was implemented. You're perfectly welcome to modify the main project files, but the officially recommended way to extend the software is to take advantage of our comprehensive plugin system. Using plugins, your changes will be easily portable between versions or environments. Let's proceed with the upgrade by creating a new version branch: Open a console on your server and change to the directory of your Cerb installation. First, you'll want to stash your local changes to files like framework.config.php, which will make merging changes easier: git stash Find the name of the remote repository. In most cases this will be origin by default. You can verify this with: git remote Fetch the branches from the remote server: git fetch origin From here you can decide which version to upgrade to: git branch -r Add a new local branch for the desired version: git branch --track 6.7 origin/6.7 Switch to the new version branch: git checkout 6.7 Re-apply your local stashed changes: git stash pop Note: If you'd prefer to use a single branch instead of one branch per version, you can use the stable branch instead of a version number. This branch will always contain the files for the most recent release, but you may have to manually merge conflicts if you've made changes to the code. In the event of conflicts... If your stashed changes were non-trivial then you may run into a situation where your changes conflict with our changes in the new version. In such a situation you can decide to merge the changes by hand, using a command like git mergetool, or you can simply reset such files to their default state with git checkout -- <file> Permissions It is possible that using version control systems like Git and Subversion will modify your file permissions. You should verify that all files are owned and readable by your webserver user, and that the /storage directory and its contents are owned and readable+writeable by your webserver user. Upgrading the database Once your files are updated to a new version, Cerb automatically brings your database up to date and migrates any relevant data to new formats. For a major upgrade there will almost always be changes to the database. This section may not apply for smaller maintenance updates. To start the database upgrade process you simply need to navigate to your helpdesk using a browser. You can also initiate this process manually by opening the /update page. For example, if your helpdesk is located at http://example.com/cerb/ then you would open http://example.com/cerb/update in your browser. Note: If you aren't using friendly URLs, then you would navigate to http://example.com/cerb/index.php/update instead. Once the database is upgraded then you'll be returned to your login form and you can resume using the helpdesk. Purge the /install directory Make sure the /install directory is deleted. It is possible for version control systems like Git to restore this directory during an upgrade. Updating Community Portals If you have Community Portals in use, like the Support Center, then it's a good idea to make sure they're using the latest version of the deployed index.php file. This file rarely changes, but you will experience subtle and difficult to diagnose problems if it does change and you don't update your portals. Navigate to Setup->Community Portals->Configure. For each Community Portal, click on it and open the Installation tab. Copy the contents of index.php to the location where your portal is installed. All done! You should be all set to take advantage of our latest improvements. Be sure to review the list of changes for the new version. [Less]

Introduction If you installed Cerb from GitHub using Git then the process of updating to a new version is simple and straightforward. If you're using Subversion, you can switch to Git with these instructions. You won't need to copy your ... [More] framework.config.php or storage directories. Everything will be upgraded in place. Check your license expiration First, verify that your license is valid for the latest version. Navigate to Setup->Settings->License in Cerb. Check the date for Software Updates Expire: If it's in the future, you're all set. Continue to the next section. If it's in the past, you either need to renew your license or upgrade to the latest version covered by your license. You can check approximate release dates from our profile on Freecode. Make a backup Refer to the instructions here to make a recent backup: http://cerbweb.com/book/latest/admin_guide/backups/ Updating the project files We recommend creating a new branch for each version of the project. With a branch per version you can make an informed decision about which of your modifications and hacks to carry over. Some of your modifications to the project files may not make sense in the latest version because your feedback was implemented. You're perfectly welcome to modify the main project files, but the officially recommended way to extend the software is to take advantage of our comprehensive plugin system. Using plugins, your changes will be easily portable between versions or environments. Let's proceed with the upgrade by creating a new version branch: Open a console on your server and change to the directory of your Cerb installation. First, you'll want to stash your local changes to files like framework.config.php, which will make merging changes easier: git stash Find the name of the remote repository. In most cases this will be origin by default. You can verify this with: git remote Fetch the branches from the remote server: git fetch origin From here you can decide which version to upgrade to: git branch -r Add a new local branch for the desired version: git branch --track 6.7 origin/6.7 Switch to the new version branch: git checkout 6.7 Re-apply your local stashed changes: git stash pop Note: If you'd prefer to use a single branch instead of one branch per version, you can use the stable branch instead of a version number. This branch will always contain the files for the most recent release, but you may have to manually merge conflicts if you've made changes to the code. In the event of conflicts... If your stashed changes were non-trivial then you may run into a situation where your changes conflict with our changes in the new version. In such a situation you can decide to merge the changes by hand, using a command like git mergetool, or you can simply reset such files to their default state with git checkout -- <file> Permissions It is possible that using version control systems like Git and Subversion will modify your file permissions. You should verify that all files are owned and readable by your webserver user, and that the /storage directory and its contents are owned and readable+writeable by your webserver user. Upgrading the database Once your files are updated to a new version, Cerb automatically brings your database up to date and migrates any relevant data to new formats. For a major upgrade there will almost always be changes to the database. This section may not apply for smaller maintenance updates. To start the database upgrade process you simply need to navigate to your helpdesk using a browser. You can also initiate this process manually by opening the /update page. For example, if your helpdesk is located at http://example.com/cerb/ then you would open http://example.com/cerb/update in your browser. Note: If you aren't using friendly URLs, then you would navigate to http://example.com/cerb/index.php/update instead. Once the database is upgraded then you'll be returned to your login form and you can resume using the helpdesk. Purge the /install directory Make sure the /install directory is deleted. It is possible for version control systems like Git to restore this directory during an upgrade. Updating Community Portals If you have Community Portals in use, like the Support Center, then it's a good idea to make sure they're using the latest version of the deployed index.php file. This file rarely changes, but you will experience subtle and difficult to diagnose problems if it does change and you don't update your portals. Navigate to Setup->Community Portals->Configure. For each Community Portal, click on it and open the Installation tab. Copy the contents of index.php to the location where your portal is installed. All done! You should be all set to take advantage of our latest improvements. Be sure to review the list of changes for the new version. [Less]

Introduction You can directly upgrade from Cerb 4.x to any version of Cerb 6.x without exporting your data or losing any of your settings. Cerb is smart enough to run all the intermediate migration scripts to bring your database up to date. ... [More] Instructions Fresh install (simple) In this guide, we'll assume your Cerb 4.x installation is at /cerb4 and your Cerb 6.x installation is at /cerb6. Download the Cerb 6.x files to a new location. You can follow the instructions in the book: http://cerberusweb.com/book/#installation Stop when you get to the section about using the guided installer since you're going to use an existing database. Make a backup of your Cerb 4.x database. Copy the following settings (by hand) from /cerb4/framework.config.php to /cerb6/framework.config.php: APP_DB_DRIVER APP_DB_HOST APP_DB_DATABASE APP_DB_USER APP_DB_PASS LANG_CHARSET_CODE DB_CHARSET_CODE AUTHORIZED_IPS_DEFAULTS Copy your attachments directory /cerb4/storage/ to /cerb6/storage/ Make sure your /cerb6/storage/ directory is writeable by the webserver. Run /cerb6/update in your web browser. [Less]

Instructions "Connection timed out" could mean a lot of things, but it's often caused by the wrong POP3 port or a firewall on the server (or ISP) blocking access to the port. If you have console access on the server, try doing a manual connection to ... [More] rule things out (in this example, 'localhost' is the name of the POP3 server): # telnet localhost 110 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK POP3 server ready. QUIT Connection closed by foreign host. If you can't get the connection to open at all, you need to make sure you're trying to connect to the right host and port. If you're certain, there is possibly a firewall blocking incoming or outbound traffic on your POP3 port (usually 110). If your server is on a residential internet account (e.g, DSL), oftentimes outbound connections on port 25 will be blocked unless you use the ISPs SMTP server. In these situations it's fine to use your ISP's SMTP (outgoing) and your own POP3/IMAP (incoming). If you need to use SSL to connect (for example, if you're using GMail), you'll need to use openssl to attempt a connection on port 995, as telnet will not work: # openssl s_client -connect pop.gmail.com:995 -quiet depth=1 C = US, O = Google Inc, CN = Google Internet Authority verify error:num=20:unable to get local issuer certificate verify return:0 +OK Gpop ready for requests from 127.0.0.1 mx4pf9618614pbc.17 If you're not able to connect, you'll need to double-check that outbound connections to port 995 are allowed within your network. [Less]

Instructions "Connection timed out" could mean a lot of things, but it's often caused by the wrong POP3 port or a firewall on the server (or ISP) blocking access to the port. If you have console access on the server, try doing a manual connection to ... [More] rule things out (in this example, 'localhost' is the name of the POP3 server): # telnet localhost 110 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK POP3 server ready. QUIT Connection closed by foreign host. If you can't get the connection to open at all, you need to make sure you're trying to connect to the right host and port. If you're certain, there is possibly a firewall blocking incoming or outbound traffic on your POP3 port (usually 110). If your server is on a residential internet account (e.g, DSL), oftentimes outbound connections on port 25 will be blocked unless you use the ISPs SMTP server. In these situations it's fine to use your ISP's SMTP (outgoing) and your own POP3/IMAP (incoming). If you need to use SSL to connect (for example, if you're using GMail), you'll need to use openssl to attempt a connection on port 995, as telnet will not work: # openssl s_client -connect pop.gmail.com:995 -quiet depth=1 C = US, O = Google Inc, CN = Google Internet Authority verify error:num=20:unable to get local issuer certificate verify return:0 +OK Gpop ready for requests from 127.0.0.1 mx4pf9618614pbc.17 If you're not able to connect, you'll need to double-check that outbound connections to port 995 are allowed within your network. [Less]

Instructions "Connection timed out" could mean a lot of things, but it's often caused by the wrong POP3 port or a firewall on the server (or ISP) blocking access to the port. If you have console access on the server, try doing a manual connection to ... [More] rule things out (in this example, 'localhost' is the name of the POP3 server): # telnet localhost 110 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK POP3 server ready. QUIT Connection closed by foreign host. If you can't get the connection to open at all, you need to make sure you're trying to connect to the right host and port. If you're certain, there is possibly a firewall blocking incoming or outbound traffic on your POP3 port (usually 110). If your server is on a residential internet account (e.g, DSL), oftentimes outbound connections on port 25 will be blocked unless you use the ISPs SMTP server. In these situations it's fine to use your ISP's SMTP (outgoing) and your own POP3/IMAP (incoming). If you need to use SSL to connect (for example, if you're using GMail), you'll need to use openssl to attempt a connection on port 995, as telnet will not work: # openssl s_client -connect pop.gmail.com:995 -quiet depth=1 C = US, O = Google Inc, CN = Google Internet Authority verify error:num=20:unable to get local issuer certificate verify return:0 +OK Gpop ready for requests from 127.0.0.1 mx4pf9618614pbc.17 If you're not able to connect, you'll need to double-check that outbound connections to port 995 are allowed within your network. [Less]

Instructions "Connection timed out" could mean a lot of things, but it's often caused by the wrong POP3 port or a firewall on the server (or ISP) blocking access to the port. If you have console access on the server, try doing a manual connection ... [More] to rule things out (in this example, 'localhost' is the name of the POP3 server): # telnet localhost 110 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK POP3 server ready. QUIT Connection closed by foreign host. If you can't get the connection to open at all, you need to make sure you're trying to connect to the right host and port. If you're certain, there is possibly a firewall blocking incoming or outbound traffic on your POP3 port (usually 110). If your server is on a residential internet account (e.g, DSL), oftentimes outbound connections on port 25 will be blocked unless you use the ISPs SMTP server. In these situations it's fine to use your ISP's SMTP (outgoing) and your own POP3/IMAP (incoming). If you need to use SSL to connect (for example, if you're using GMail), you'll need to use openssl to attempt a connection on port 995, as telnet will not work: # openssl s_client -connect pop.gmail.com:995 -quiet depth=1 C = US, O = Google Inc, CN = Google Internet Authority verify error:num=20:unable to get local issuer certificate verify return:0 +OK Gpop ready for requests from 127.0.0.1 mx4pf9618614pbc.17 If you're not able to connect, you'll need to double-check that outbound connections to port 995 are allowed within your network. [Less]