Running out of disk space on Linux Mint partition, changing the MySQL data directory

I bought a PC with Linux Mint 17 already installed. This is my first time working on a Linux system, so there's been a bit of a learning curve.

Things were going along pretty well until I started to get all kinds of weird errors.

• A text file that I maintain manually had the last part of its contents truncated from the last time I had saved it.

• I could not log in to phpMyAdmin even though I knew the username and password were correct.

• An initial install of Drupal 7 would not come up with its front page. A PDO error on a SQL query was being reported.

Eventually I suspected something related to databases, happened to run the Disk Usage Analyzer and found that one of the disk partitions had run out of space. Oh, joy.

It turns out that the system I got was configured with three partitions. On the File Systems tab of the System Monitor app, it shows the partitions and their total sizes as

/dev/sda1   /boot  463.9 MiB
/dev/sda5   /       18.6 GiB
/dev/sda6   /home  215.4 GiB

By default, MySQL 5.5 stores its data on /var/lib/mysql which is on the / partition which has about 18 GiB allocated to it.

That partition was not large enough for the Drupal 7 database along with everything else that was there, which apparently includes the system itself and apps that I had earlier installed.

Looking at these space allocations, I inferred that /home is where user data of all sorts is intended to be kept.

So I used the sources listed below to figure out how to change where MySQL stores its data.

(0) But first, I figured I should clean up the mess I had already created by uninstalling phpMyAdmin, and then completely uninstalling MySQL.

(I carried out all the commands in this post while logged in as root. Alternatively, you could use sudo instead.)

# apt-get remove phpmyadmin

# /etc/init.d/mysql  stop
# apt-get remove mysql-server
# cd /var/lib
# rm -r mysql

# apt-get autoremove

That last command is to remove any packages that are no longer needed on the system. I'm pretty fussy about not keeping useless clutter around.

(1) Then, re-installed MySQL 5.5.

# apt-get install mysql-server

(2) Changed the MySQL data directory to use the much larger partition. In my case, I chose to put the data directly under /home

# /etc/init.d/mysql  stop
# cp -R -p  /var/lib/mysql  /home

# cd /var/lib
# rm -r mysql

# ln -s  /home/mysql  /var/lib/mysql

That last command is to provide a symbolic link from the default directory to the real one. Otherwise, you can edit the datadir setting in the MySQL configuration file /etc/mysql/my.conf

Note that the MySQL logs are still located in  /var/log/mysql

(3) The final step was to deal with the AppArmor app.

Edited /etc/apparmor.d/usr.sbin.mysqld to change from

  /var/lib/mysql/ r,
  /var/lib/mysql/** rwk,

to

  /home/mysql/ r,
  /home/mysql/** rwk,

I couldn't find the apparmor app mentioned in the source articles. Instead, I rebooted in order for these AppArmor security changes to take effect. (Could the AppArmor functionality be baked into the Linux Mint system?)


Sources:

How to change the MySQL data default directory
http://www.ubuntugeek.com/how-to-change-the-mysql-data-default-directory.html

Linux Ubuntu move mysql database to other path in 5 minutes
http://article.my-addr.com/?show=linux_ubuntu_change_datadir-move_mysql_database_to_other_path

How to Remove MySQL Completely from Linux System
http://tecadmin.net/remove-mysql-completely-from-linux-system/

Setting up xDebug with Sublime Text under Linux Mint

I wrote an earlier post about setting up the xDebug PHP debugger with the Sublime editor under Windows 7.

I'm now migrating to developing on a Linux system and have done this set up for Sublime Text 3 and Linux Mint 17.

This post borrows heavily from the earlier article. 

(1) Installed xDebug 2.2.3 extension for PHP.

(a) While logged in as root,

  # apt-get  install  php5-xdebug

This installed the php5-xdebug package, creating the two files

  /usr/lib/php5/20121212/xdebug.so
  /etc/php5/apache2/conf.d/20-xdebug.ini

On your system, the path for xdebug.so may be a little different.

20-xdebug.ini is actually a link to the file mentioned in step (2) below.

(b)  Restarted Apache. Loaded a page containing a call to phpinfo() to check that the extension was installed. On the page there appeared an xdebug section with several tables that showed settings and directives.

(2) Added directives for xDebug.

Edited /etc/php5/mods-available/xdebug.ini to include the following lines.

  xdebug.remote_enable = On
  xdebug.remote_host = "localhost"
  xdebug.remote_port = 9000
  xdebug.remote_handler = "dbgp"
  xdebug.remote_autostart = On
  xdebug.remote_mode = req
  xdebug.remote_connect_back = 0 

Because I only want to debug locally, I set xdebug.remote_connect_back to 0 to turn it off. I believe this should be set to 1 if you intend to debug a site running on a remote system.

(3) Installed the Sublime package manager, "Package Control".

(a)  Within Sublime, clicked Preferences > Browse Packages, then browsed up one level to find the full path for the Installed Packages folder. On my system the path is

  ~/.config/sublime-text-3/Installed Packages

(b)  Downloaded the file Package Control.sublime-package from 

   https://sublime.wbond.net/Package%20Control.sublime-package

(c)   Copied that file into the Installed Packages directory.

(d)  Re-started Sublime.

In Sublime's Command Palette window, various Package Control commands are then available on the palette and elsewhere.

(4) Using Sublime's Package Control, installed the Xdebug Client package.

  Tools > Command Palette ...  >  Package Control: Install Package

Typed Xdebug Client into the search field, and clicked on Xdebug Client in the search results to install.

This adds a submenu, Tools > Xdebug, or you can use the keyboard equivalents.

(5) To start an xDebug session.

To start a debugging session, I load the site by appending the query string ?XDEBUG_SESSION_START=1  to the initial url, like so.

  http://localhost/power-poetry/?XDEBUG_SESSION_START=1 

The value of  XDEBUG_SESSION_START  is a session name that is stored in a cookie, so it probably could be any name you choose.

There are other ways to start an xDebug session, but for getting started with using this debugger, this seems like the simplest.

Finally, in Sublime itself, to activate the editor as an xDebug client,

  Tools > Xdebug > Start  Debugging


Sources:

Debug PHP with Xdebug in Sublime Text 2 (in Linux mint)
http://saml.rilspace.org/debug-php-with-xdebug-in-sublime-text-2-in-linux-mint

XDEBUG EXTENSION FOR PHP
http://xdebug.org/docs/remote

martomo / SublimeTextXdebug
https://github.com/martomo/SublimeTextXdebug

Package Control
https://sublime.wbond.net/installation#st2

Download:  Package Control.sublime-package
https://sublime.wbond.net/Package%20Control.sublime-package

Beta 1 --> Beta 3: No module code changes !!

Running the Optimizely module under Drupal 8, beta 3, both manual and automated testing showed no loss of functionality or run-time errors. This is the first time that migrating to a new release of D8 did not require any code changes to the module.

All I had to do was bump up its version number. The reason I made a new release of the module is to show that it has been tested and conforms to the new D8 beta. My current convention is to incorporate the D8 version as part of the module version, like so:  8.x-2.15-beta3.

All blog posts have been updated for Beta 1

I have completed a review of all posts in this blog with respect to Drupal 8, beta 1, to check whether they are up to date.

Where there have been significant changes, rather than edit the original content, at the bottom of the article I added brief notes and links to newer posts that describe updates that have taken effect.

In one or two cases, there were enough code changes to warrant a fresh sample of code in a new posting.

The result is that this collection of articles remains reasonably up-to-date and accurate as we move into the beta releases of D8.

Happy Drupaling.

Implementing a form, D8 beta 1

I wrote an earlier post about the rudiments of how to implement a simple form for Drupal 8. There have been several related API changes since then, but that post has a number of notes that are still accurate and useful.

The original post is at http://optimizely-to-drupal-8.blogspot.com/2014/05/implementing-forms.html   You really should read that post first, then come back to this one for the current code.

In this posting, I am only providing an update of the code sample for the class that defines the form. You may want to read the earlier post as well.

Again, this is  only an extract from the class definition. To keep it short and to the point, I've omitted parts of the bodies of the methods as well as boilerplate comments. 

Code changes from the original post are in boldface.


namespace Drupal\optimizely;
 
use Drupal\Core\Form\FormBase;
use Drupal\Core\Form\FormStateInterface;
 
class AccountInfoForm extends FormBase {

  public function getFormID() {
    return 'optimizely_account_info';
  }
 
  public function buildForm(array $form, 
                            FormStateInterface $form_state) {    
    $form['optimizely_id'] = array(      
      '#type' => 'textfield',
      '#title' => t('Optimizely ID Number'),
      '#size' => 60,
      '#maxlength' => 256,
      '#required' => TRUE,
    );
    $form['actions'] = array('#type' => 'actions', );
    $form['actions']['submit'] = array(
      '#type' => 'submit',
      '#value' => 'Submit',
    );

    return $form;
  }
 
  public function validateForm(array &$form,
                               FormStateInterface $form_state) {
    $oid = $form_state->getValue('optimizely_id');
 
    if (!preg_match('/^\d+$/', $oid)) {
      $form_state->setErrorByName(
        'optimizely_id',
        t('Your Optimizely ID should be numeric.'));    }
  }
 
  public function submitForm(array &$form, 
                             FormStateInterface $form_state) {
    // Code to update the database ...
    //    . . . . .

    drupal_set_message(t('The default project ...'),
                       'status');    
    // Redirect back to projects listing.
    $form_state->setRedirect('optimizely.listing');
    return;
  }
}  

Related Posts.

Drupal 8: alpha 13 --> alpha 14
http://optimizely-to-drupal-8.blogspot.com/2014/08/drupal-8-alpha-13-alpha-14.html

FormStateInterface, and drupal_valid_path()
http://optimizely-to-drupal-8.blogspot.com/2014/09/formstateinterface-and-drupalvalidpath.html