The [sometimes] trouble with updates

No, I am not referring to Windows updates. Instead, I am referring to Linux updates. There are mixed views on whether you should do updates or not on your system(s). Here is my view.... if it is a server, update it ONLY when you are absolutely needing to. This means only if there is a security hole that is fixed by a newer version. On the other hand, if it is a desktop system, if you update then it is up to you.

If you do updates though, you really need to watch out. Make sure you know what exactly is happening during the update(s) as things tend to change and also stop working.

I did an update earlier this evening after booting up my laptop. No worries, right? Wrong. When I tried to start my apache web server (which was previously installed and working fine), I discovered that it was no longer working. Strange if you ask me, but it wasn't starting up. It kept giving me the same errors:

# /etc/init.d/apache2 start
* Starting web server apache2 [Fri Oct 24 22:15:10 2008] [warn] module php5_module is already loaded, skipping
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs

I started by plugging in the different errors into Google, but kept going in directions I didn't think were the answer. Then I looked at the last error: "Unable to open logs". That was odd because I hadn't changed anything, but...... then there was the updates.

So I checked and the /var/log/apache2 directory and saw that it was owned by root and had a group of adm. I distinctly remember that being the group root the other day. So, instead of changing permissions (which is someting I was not wanting to do, I decided to add root to the adm group.

I restarted apache and VOILA!!! Problem fixed. So, the lesson.... know what updates are being applied and if something doesn't work afterwards, you will at least know why.

Linux Filesystem Layout

I was "stumbling" around and I stumbled across a page that showed a graphical layout of the Linux Filesystem. For those that are beginning in their Linux ventures, I can imagine that this will be quite helpful. Without an understanding of the filesystem, a lot of things will be lost in your learning process, so learn it well.

A change to my previous posting

In my previous posting of MySQL commands, #6 talked about granting permissions to a user on all databases. It should be noted that it is much wiser to first:

- create the user account in mysql first and set the password.
- then, set the permissions that the user has for said database(s).

Some useful MySQL commands

Lately I have been getting quite intimate with the MySQL database and have been doing things beyond the standard queries and adds. Here is a list of some other useful commands that I have been working with lately. Please know that any options to these commands that are in [ ] are considered optional:

1. Delete a databse:

Format: drop {database | schema} [if exists] db_name;

This command drops all tables in the database and then deletes the database. You need to have 'drop' privilages to do this. *Note: As of MySQL 5.0.2 "schema" is a synonym for database.

2. Delete a table:

Format: drop [temporary] table [if exists] table_name[, tablename, ...] [restrict | cascade];

This command will delete one or more tables from a database. Again, you must have drop permissions for each table.

3. Back up a table to file (in case a recovery is needed after doing something like an alter on a table):

CLI Format: mysqldump --user=<username> --password -B <database_name> --tables <table_name> > filename.sql

This command should be issued from the command line, not from within mysql's interface, as the two previous commands would be. The '.sql' extension on the file tells you that the data inside is for sql. If you open the file, you will see a plethora of sql commands to recreate the table as it was.

4. Restore a table from a backup sql file:

CLI Format: mysql -u <username> -p <database_name> < filename.sql

This will restore the table to its original glory.

5. Delete all data from a table:

Format: truncate <table_name>;

This will erase all data from the table, leaving the defined schema in tact.

6. Grant permissions on database's to a specific user:

Format: grant {comma separated permissions list} on <db_name>.* to `username`@`localhost`;

This will grant whatever permissions needed to the specified user. Now, if the user account in MySQL does not exist, then after the username@localhost piece, you will need to specify:

identified by password `password`;

Now, the tic marks around `password` and `usrename`@`localhost` are all back tics. That is what I tend to use and have never had a problem.

One note of caution, BE CAREFUL using the above commands. They are commands that will cause serious changes to your database and tables. Practice on a test database before doing ANYTHING on a production database. Also, make sure to back up any tables or databases that you work on. As we all know, whatever can happen.... usually will.