Category: Troubleshooting

Beginner’s Guide to Error Handling in PHP – Part 1

Learn the basics of error handling in PHP. Understand production safety and developer insights with logging errors using error_reporting.

Effective error handling in PHP is essential for developers—it helps identify issues while keeping your production environment secure and user-friendly.

Balancing Error Display vs. Security

On a production server, showing PHP errors directly on the screen poses security risks, as they may reveal sensitive file paths or internal logic. Hence, many developers suppress error display using:

ini_set('error_reporting', 0);
error_reporting(0);

ini_set('display_errors', FALSE);

However, completely hiding errors without logging them makes debugging nearly impossible.

Capturing and Logging Errors Safely

A more practical approach is to keep errors hidden from users but log them for developers to review, like below:

ini_set('error_reporting', E_ALL);
error_reporting(E_ALL);

ini_set('log_errors', TRUE);
ini_set('html_errors', FALSE);
ini_set('error_log', LOG_PATH.'error.log');

ini_set('display_errors', FALSE);

Explanation:

  • Enable reporting for all errors (E_ALL), ensuring nothing is missed.
  • Direct errors to logs, turning off HTML formatting (html_errors = FALSE) for cleaner log formatting.
  • Specify a custom log file path (via LOG_PATH . 'error.log'), enabling modular logging for different parts of your application.
  • Disable display of errors to protect end users from seeing raw error output.

Benefits of This Approach

  • Production safety: Users can’t see system internals or error details.
  • Developer insight: All error information will be logged in centralized log files.
  • Modular logging: You can segregate logs per module for quicker diagnostics.

Would you like to learn advanced error handling techniques in PHP like exceptions, custom handlers, or reading log files? Just let me know—happy to continue!

Setup and use a virtual python environment in Ubuntu

With virtualenvwrapper (user-friendly wrappers for the functionality of virtualenv)

Install virtualenv

Install virtualenv with

sudo apt-get install virtualenv

(for Ubuntu 14.04 (trusty) install python-virtualenv)

Install virtualenvwrapper

The reason we are also installing virtualenvwrapper is that it offers nice and simple commands to manage your virtual environments. There are two ways to install virtualenvwrapper:

As Ubuntu package (from Ubuntu 16.04)

Run sudo apt install virtualenvwrapper then run echo "source /usr/share/virtualenvwrapper/virtualenvwrapper.sh" >> ~/.bashrc

Using pip

  1. Install and/or update pip

    Install pip for Python 2 with
    sudo apt-get install python-pip

    or for Python 3
    sudo apt-get install python3-pip

    (if you use Python 3, you may need to use pip3 instead of pip in the rest of this guide).

    Optional (but recommended): 
    Turn on bash autocomplete for pip Run
    pip completion --bash >> ~/.bashrc

    and run 

    source ~/.bashrc 

    to enable.
  2. Install virtualenvwrapper Because we want to avoid sudo pip we install virtualenvwrapper locally (by default under ~/.local) with:
    pip install --user virtualenvwrapper

    and

    echo "export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3" >> ~/.bashrc
  3. Source virtualenvwrapper in .bashrc

    echo "source ~/.local/bin/virtualenvwrapper.sh" >> ~/.bashrc

Setup virtualenv and virtualenvwrapper:

First, we export the WORKON_HOME variable which contains the directory in which our virtual environments are to be stored. Let’s make this ~/.virtualenvs

export WORKON_HOME=~/.virtualenvs

now also create this directory

mkdir $WORKON_HOME

and put this export in our ~/.bashrc file so this variable gets automatically defined

echo "export WORKON_HOME=$WORKON_HOME" >> ~/.bashrc

We can also add some extra tricks like the following, which makes sure that if pip creates an extra virtual environment, it is also placed in our WORKON_HOME directory:

echo "export PIP_VIRTUALENV_BASE=$WORKON_HOME" >> ~/.bashrc

Source ~/.bashrc to load the changes

source ~/.bashrc

Test if it works

Now we create our first virtual environment. The -p argument is optional, it is used to set the Python version to use; it can also be python3 for example.

mkvirtualenv -p python2.7 test

You will see that the environment will be set up, and your prompt now includes the name of your active environment in parentheses. Also if you now run

python -c "import sys; print sys.path"

you should see a lot of /home/user/.virtualenv/... because it now doesn’t use your system site packages.

You can deactivate your environment by running

deactivate

and if you want to work on it again, simply type

workon test

Finally, if you want to delete your environment, type

rmvirtualenv test

Enjoy!

How to Autostart GlassFish Server on Ubuntu Startup

Learn how to configure GlassFish Server to start automatically on system boot in Ubuntu. Step-by-step guide using systemd service scripts.

If you want GlassFish Server to launch automatically when your Ubuntu system boots, you can easily achieve that by creating an init script. This allows you to manage GlassFish’s start, stop, and restart actions seamlessly.

In this article, we learn to create the init script for GlassFish server and how to configure it in Ubuntu systems to control GlassFish server.

Step 1: Create the Init Script

The init script file for GlassFish Server is to be created at /etc/init.d/.

For managing all GlassFish Server startup events, it ships with the asadmin tool. Use this tool in the startup script as follows,

Create GlassFish init file using the following command:

sudo nano /etc/init.d/glassfish

Paste the following lines in the file

#!/bin/sh
# Prevent potential issues by defining Java path
export AS_JAVA=/usr/lib/jvm/jdk1.8.0
GLASSFISHPATH=/home/glassfish/bin

case "$1" in
  start)
    echo "Starting GlassFish from $GLASSFISHPATH"
    sudo -u glassfish $GLASSFISHPATH/asadmin start-domain domain1
    ;;
  stop)
    echo "Stopping GlassFish from $GLASSFISHPATH"
    sudo -u glassfish $GLASSFISHPATH/asadmin stop-domain domain1
    ;;
  restart)
    $0 stop
    $0 start
    ;;
  *)
    echo "Usage: $0 {start|stop|restart}"
    exit 3
    ;;
esac

This script uses asadmin to control the domain named domain1, running it as a dedicated glassfish user for security and proper permissions.

Step 2: Make the Script Executable

Now, glassfish startup script is created. We need to add this file in startup to make Glassfish Server autostart during Ubuntu startup.

Set the appropriate permissions so the system can run it at boot:

sudo chmod a+x /etc/init.d/glassfish

Step 3: Register the Script to Run at Startup

Link it into Ubuntu’s init system to execute during startup:

sudo update-rc.d glassfish defaults

This ensures the script will be triggered automatically during system boot.

Step 4: Validate the Setup

Now, restart Ubuntu and check if it really autostart the Glassfish Server.

Step 5: Validate Manual Commands

You can also manage Glassfish Server startup events as follows,

sudo /etc/init.d/glassfish start  # Start the server
sudo /etc/init.d/glassfish stop   # Stop the server
sudo /etc/init.d/glassfish restart  # Restart the server

Conclusion

Setting up GlassFish to start automatically on boot ensures that your applications and services are always available after a system reboot—without requiring manual intervention. By creating a simple init script and registering it with Ubuntu’s startup sequence, you can streamline your server management and reduce downtime. This method is especially useful for production environments where stability and automation are critical.

If you’re using a newer Ubuntu version that defaults to systemd, consider switching to a systemd service file for even better control and logging.

Auto-Start Tomcat on Ubuntu Boot Using systemd

Learn how to configure Apache Tomcat to start automatically on system boot in Ubuntu using systemd service units. A complete step-by-step guide.

Apache Tomcat is not configured with autostart by default in Ubuntu. So, custom init script is required to configure Tomcat for autostart on startup.

Create the init script in /etc/init.d/tomcat8 with the contents as per below.

Init script contents:

#!/bin/bash

### BEGIN INIT INFO
# Provides:        tomcat8
# Required-Start:  $network
# Required-Stop:   $network
# Default-Start:   2 3 4 5
# Default-Stop:    0 1 6
# Short-Description: Start/Stop Tomcat server
### END INIT INFO

PATH=/sbin:/bin:/usr/sbin:/usr/bin

start() {
 sh {tomcat_root}/bin/startup.sh
}

stop() {
 sh {tomcat_root}/bin/shutdown.sh
}

case $1 in
  start|stop) $1;;
  restart) stop; start;;
  *) echo "Run as $0 <start|stop|restart>"; exit 1;;
esac

Note: Please change {tomcat_root} with your Tomcat installation folder path.

Change its permissions and add the correct symlinks automatically:

chmod 755 /etc/init.d/tomcat8
update-rc.d tomcat8 defaults

And from now on it will be automatically started and shut down upon entering the appropriate run levels.

It could be also controlled with just use following commands like Apache

service tomcat8 <stop|start|restart>

Using above process any server script can be created and configured to start on startup.

Accessing PostgreSQL via SSH Putty tunnel

Learn how to securely access a remote PostgreSQL database through an SSH tunnel using PuTTY on Windows. Step-by-step configuration guide included.

To close the port 5432 for any traffic or don’t want to configure PostgreSQL to listen to any remote traffic, use SSH Tunneling to make a remote connection to the PostgreSQL instance at AWS.

Follow these steps to connect PostgreSQL using SSH Tunneling at AWS:

  1. Open PuTTY. Setup server session in Putty.
  2. Go to Connection > SSH > Tunnels
  3. Enter 8000 in the Source Port field.
  4. Enter 127.0.0.1:5432 in the Destination field.
  5. Click the “Add” button.
  6. Go back to Session, and save, then click “Open” to connect.
  7. This opens a terminal window. After connection leaves that alone.
  8. Open pgAdmin and add a connection.
  9. Enter localhost in the Host field and 8000  in the Port field.
  10. Specify a Name for the connection, and the username and password. Click OK.

What is it doing? PuTTY is intercepting communications sent from pgAdmin to localhost:8000. The information is transferred across the internet via SSH, on port 22. When it arrives there, the SSH server sends the information on to PostgreSQL via port 5432. As far as PostgreSQL knows, the traffic came in locally, on the correct port.