BIOSTALL

Over the past couple of days I’ve been setting up a new box running Windows Server 2008 r2. One of the main requirements for it was that it should be able to accept file uploads via FTP. This wasn’t too much of a problem and seemed to be relatively easy… Install the IIS role, install the FTP service and setup an FTP site along with any associated users.

All was going well and I was able to connect to the server remotely as a standard user with no problem at all. When I came to upload a file however I started to get the following error:

550 Access is denied

The Solution

After a bit of investigation I managed to solve the problem by following the steps below:

1. Open the ‘Internet Information Services (IIS) Manager’. You should be able to find this in your Start menu under ‘Administrative Tools’.

2. Once opened, right-click your FTP site and select ‘Edit Permissions…’ from the menu:

3. Select the ‘Security’ tab.

4. Click the ‘Users’ group. You can see from the permissions shown underneath that by default this group doesn’t have ‘Write’ permissions:

5. Click ‘Edit…’ and select to allow the ‘Write’ permission:

6. Click ‘OK’ to save the changes.

Once the above change has been performed you should now be able to successfully upload files without problem.

Upon trying to login to SugarCRM ealier today I kept getting an error stating “You have been logged out because your session has expired”. I knew the details were correct but no matter how many times I tried the same message kept coming up and I could not login. Upon fumbling around for a while I came across a couple of solutions, one of which resolved the problem. I explain these in more detail below:

Solution One – Session Directory Not Writable

This first solution wasn’t relevant in my case but I did see it mentioned a few times on my travels as a very likely resolution to the problem mentioned above and thought it worth a mention it here.

When you’re logged into SugarCRM it uses PHP sessions to store information about your current visit. This solution suggests that the directory where this session information is stored is not writable and therefore SugarCRM is unable to continue past the login screen.

So where is this directory? The first place to look is in your SugarCRM configuration file. This can found in the root of your SugarCRM installation and is in a file called config.php. Within this PHP file is a reference to where sessions will be stored. If this contains a valid path then ensure SugarCRM has permission to write to it.

If the above path in config.php is blank then SugarCRM will use the path set in the php.ini file. You can view what this is set to by creating a PHP file and entering the following:

echo ini_get("session.save_path");

Solution Two – Disk Out Of Space

The other possible cause of the error was that the disk where SugarCRM is located was out of space which was the case in my scenario. By simply deleting a few old backups and cleaning down unused files I was then able to login again immediately.

Whilst recently carrying out a security audit, one of the tasks on my list was to refine the permissions that MySQL users have. One of the users in the list was called ‘admin’. It had full permissions to all databases which struck me as a bit unsafe so, seeing as I wasn’t using this MySQL user on any of my sites, I struck (maybe a bit too hastily) and deleted it. From here on in things went downhill…

It’s probably worth mentioning at this point that I use the Plesk control panel to manage various aspects of my server; from database access to setting up cronjobs. I know this could all be done via the command line but by doing it through the Plesk GUI it makes carrying out tasks generally quicker.

It was at the moment I deleted the MySQL admin user that I started to receive the following error when trying to access Plesk:

The service is not available now.
Some Container resources are overused. Click to see the details.

The error was definitely misleading and didn’t relate in anyway to the deleted MySQL user. Regardless, I was certain the two were linked so my first point of call was to reinstate the admin user I had just deleted. But how do you add a MySQL user with full permissions when you a) don’t have any other MySQL users available or b) don’t have another MySQL user available to log in as with high enough privileges to create more users.

The Solution

After lots of digging around I found the solution to add the admin user to MySQL and managed to get access back into Plesk by following the steps below:

1. Log onto the Linux command line using a tool like Putty.

2. Navigate to your MySQL configuration file and open it in an editor. For me this was located at /etc/my.cnf:

$ nano /etc/my.cnf

3. Add the following line to my.cnf on a blank line:

skip-grant-tables

By adding ‘skip-grant-tables’ we are telling MySQL that permissions are out of the window and anyone can get access to everything. It goes without saying that we’ll need to remember to remove this later on.

4. Save and close my.cnf and restart MySQL so the updated configuration comes into effect:

$ /etc/init.d/mysqld restart

5. Once the MySQL service has restarted the next step is to add our ‘admin’ user back in. First, lets log onto the MySQL command line like so:

$ mysql

Notice how we don’t need to add any user credentials? This is the configuration option we added above in effect.

6. Next lets change to the ‘mysql’ database:

mysql> use mysql;

The ‘mysql’ database is where MySQL stores it’s configuration settings, as well as user information and permissions.

7. Now it’s time to add the ‘admin’ user back in where it belongs. We can achieve this by running the following query:

mysql> CREATE USER 'admin'@'localhost' IDENTIFIED BY 'your_plesk_password';

8. Good. Now it’s time to grant this new user some privileges:

mysql> GRANT ALL PRIVILEGES ON *.* TO 'admin'@'localhost' WITH GRANT OPTION;

9. And finally, to bring our reinstated user and all it’s permission into effect we need to flush the privileges:

mysql> FLUSH PRIVILEGES;

At this point in the process you should now be able to log into Plesk successfully. If you’re already logged in I recommend you log out and then log back in again. Fingers crossed it should all be back to normal.

Remember…

The last thing to remember to do is to undo what we did in step 3 above. Simply repeat steps 1-4 and remove or comment out the option.

When viewing and editing files, Linux’s nano command can be very useful. One of the primary reasons for my usage of nano is reading log files that can be hundreds, if not thousands of lines long. In this scenario one of the most useful commands required is to quickly jump to the top and bottom of the file, especially seeing as log files are normally date ordered. As a result I wanted to share with you how to do this in just a couple of keystrokes.

Jump to the bottom of the file

The are two steps involved in doing this. The first is to press ‘Ctrl + _’ (underscore). This will ask for a line number at which point then press ‘Ctrl + V’. This will move the cursor directly to the bottom of the file.

Jump to the top of the file

This process is similar to the above but instead of pressing ‘Ctrl + V’, press ‘Ctrl + Y’. Voila, you’re back at the top in just four keystrokes.

With a system thats regularly creating files on-the-fly it’s important to keep track of the filesizes to monitor disk usage. One of the daily tasks I perform is to track the filesize of files created within the last day by running the following on the command line:

find /directory_name -iname "*.zip" -mtime -1 -printf "%p %k\n"

By running the above you will be presented with a list of all ZIP files modified in the last 24 hours along with the filesize of each. Let me break it down a bit further:

find

‘find’ is a linux command used to locate files on the Linux system. Used in conjunction with additional parameters it can be a powerful command to find a set of specific files.

/directory_name

This is the directory that we wish to search within. All subdirectories of this specified folder will also be included in the search.

-iname "*.zip"

Used to locate all files with a ‘.zip’ extension.

-mtime -1

Here we specify the modified date of the files that we wish to return. In this scenario we are saying show all files modified within the last 1 day.

-printf "%p %k\n"

This is the format of the files output to screen. %p correponds to the filename and %k relates to the size of the file in kilobytes. Each file will be separated by a new line (\n).

I had a scenario recently where bandwidth usage on a server was becoming an issue. As a result the need arose to find out if any third party websites or scripts were excessively referencing the server.

To do this, one of the steps taken was to identify and locate any IP addresses repeatedly appearing in the access log. Once logged onto the command line and having navigated to the access log directory the following command was ran:

time awk '{!a[$1]++}END{for(i in a) if ( a[i] >100 ) print a[i],i }' access_log

The above gets all IP addresses that appear in the access log more than 100 times and outputs something similar to the below:

254 82.196.159.210
332 62.279.72.198
103 99.220.192.102
344 95.118.151.264
521 51.214.222.227

real    0m0.006s
user    0m0.002s
sys     0m0.004s

Note: IP addresses shown in the above example have been made up

Being a fan of staying on top of the latest technology I was excited when I saw that WordPress 3.2 had been released. Not only from a functionality point of view, but a security one too. It boasted many improvements that I was keen to get my hands on.

Upon going to update WordPress I discovered that my version of PHP was too old and that I needed to upgrade to PHP 5.2.4. I’d never done a PHP update before but after a little time spent searching (and building up the courage) I managed to perform the upgrade by following the instructions provided by Jason Litka here.

All in all the update seemed to go as planned and as described in the instructions, however when I then went to visit any of my sites I was getting MySQL errors about not being able to connect to the MySQL server. I booted up Plesk and it seemed that the MySQL service was not running. I was unable to start the service using plesk or via the command line using the following command:

/etc/init.d/mysqld start

‘FAILED’ was the reponse. Not a very helpful response albeit but solid confirmation that something wasn’t right here. Checking the MySQL log was my next step to see if I could find a more helpful explanation as to the cause of the problem. I opened the log by using the following the command:

nano /var/log/mysql/mysql.log

Note that the path above may differ based on what’s stated in your MySQL configuration file.

At the very bottom of the log was the following output:

090701 19:10:48  mysqld started
090701 19:10:49  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite

Again, this didn’t prove very helpful at first glance but it was clear that something wasn’t quite right with the setup since the update.

The Solution

Finally, after much time trying to figure out the issue I had got it. Allow me to explain…

Located on the server is a file called my.cnf that stores all the configuration options that relate to the MySQL service. Upon performing the update the original my.cnf file was not updated, but instead a new version was created called my.cnf.rpmnew. I compared these two files and saw the following:

my.cnf

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

# To enable the InnoDB Plugin, uncomment the 2 next lines
#ignore-builtin-innodb
#plugin-load=innodb=ha_innodb_plugin.so

# To enable InnoDB-related INFORMATION_SCHEMA tables
# Join the following options to above directive
  ;innodb_trx=ha_innodb_plugin.so
  ;innodb_locks=ha_innodb_plugin.so
  ;innodb_cmp=ha_innodb_plugin.so
  ;innodb_cmp_reset=ha_innodb_plugin.so
  ;innodb_cmpmem=ha_innodb_plugin.so
  ;innodb_cmpmem_reset=ha_innodb_plugin.so

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

my.cnf.rpmnew

[mysqld]
set-variable=local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
skip-networking

skip-bdb

set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
skip-bdb

set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2

As you can see the two differ quite a bit. To sort the issue I simply renamed the new version to be the same as the original like so:

mv my.cnf.rpmnew my.cnf

Holding my breath I attempted to start the MySQL service again and it fired right up bringing all my sites back to life.