Feb 5 01:39:33 server named: zone myzone.com/IN: serial number (12331465) received from master 127.0.0.2#53 < ours (200901281)
This can be annoying, it can happen for a variety of reasons. What seems to be happening here is that the slave realizes the time on the slave is ahead of the master, so it therefore assumes it has the most up to date copy and won't actually transfer the zone.
rndc retransfer myzone.com
*Replace "myzone.com" with the actual name of the domain you want to transfer to the slave (of course the slave must already have the domain defined in /etc/named.conf. Remember that "myzone.com" is the domain name, even if you have a zone file called "myzone.com.db" you wouldn't type that or it won't work.
The command above forces BIND to transfer the zone no matter what.
I was getting very frustrated one day wondering why it appeared my .htaccess file was being ignored and not processed by Apache. No matter what I did it was obvious that Apache didn't care about my .htaccess file. Then I realized that the default settings must be in effect, which is that my vhost didn't explicitly allow me to override the default settings.
This usually comes down to your vhost settings. Make sure you have an entry like this in your Apache vhost settings in order for .htaccess files to be processed, otherwise the default .htaccess settings in /etc/httpd/conf/httpd.conf are what take effect.
As you can see above, you just need an entry like this to fix the problem. Be sure that the path in the <Directory directive is the one to your document root for the vhost in order to get the desired results.
Now your htaccess files will work just fine in Apache as you intended them to.
mysqldump --all-databases -u admin -p > allmysqldatabases.sql
The "-all-databases" clause is pretty obvious isn't it? It means that it will backup all databases.
The "-u admin" means login using the user "admin", if you have another user such as root or a specific user that can access/dump all databases you can use that one.
The "> allmysqldatabases.sql" part tells it to output all the database information to a file called "allmysqldatabases.sql" and don't forget the ">" as that is redirection and is what writes all the info to a file. Without redirecting the output, you'll see lines and lines of gibberish on your screen, because otherwise MySQL assumes you want to print all the output to the screen.
This method is a quick and dirty way to migrate several databases at once. After that if you want to get fancy, you can gzip your database dump, this will protect against unknown data corruption and of course make the file transfer quicker since compressing with gzip reduces the size.
For example the file was originally 279MB and gzip took it to 179MB.
To gzip your backed up mysql databases just run this command (works on any file other than just .sql dumps of course):
mysqldump --databases mysql -u admin -p > mysqlbackup.sql
The "--databases" clause specifies you are going to backup one or more database as specified in the command.
If you wanted databases "mysql" and "someothedb" you would use "--databases mysql someotherdb"
mysqldump -u user -p databasename tablename tablename > thetable.sql
As you can see after specifying the db name you can specific as many tables you want. By default the tables will be populated with the data. If you just want the structure use this instead.
mysqldump -d -u user -p databasename tablename tablename > thetable.sql
The "-d" switch causes only the structure to be dumped.
What fun is backing up without being able to restore? Restoring can be a bit more tricky and there's a few different scenarios and options you have.
I'll focus on the most common one, a new MySQL Server install with no previous data or tables.
I'm assuming you've transferred your database backup "allmysqldatabases.sql.gz"
To restore all your database(s) and information to MySQL just run this following command:
mysql -u root < allmysqldatabases.sql
mysql -u $username --password="$password" --database="$dbname" < $sqlscript
One issue I have is that despite backing up and restoring the database "mysql" I cannot authenticate successfully with my old login information. I don't know why because a query of the mysql table shows the usernames I am expecting to see.
I'll have to research more on this point, but the good news is that all the other tables/databases and entries are there as expected.
I knew everything was there and that the "mysql" table was fully populated. All I had to do was restart mysql server (mysqld) and everything worked as normal with the old passwords and privileges I originally had.
I was getting really annoyed with this, I used full quotes around the filename and vi, cat, less all thought I was trying to pass the dash in the filename as an argument.
I didn't realize that all you have to do is just put a dash dash "--" in front.
Here's an example:
cat -- "-etc-glusterfs-glusterfsd.vol.log"
Without the -- you get:
cat: invalid option -- c
Try `cat --help' for more information.
I hope this saves someone else some trouble. I never thought that a dash of anything could fix such an annoying problem :)
I still think it's not preferable to have a filename which starts with a - but gusterfs thinks it is a smart thing for now.
100215 07:02:24 mysqld started
/usr/libexec/mysqld: Can't read dir of '/tmp/' (Errcode: 13)
/usr/libexec/mysqld: Can't create/write to file '/tmp/ibyP1qUC' (Errcode: 13)
100215 7:02:24 InnoDB: Error: unable to create temporary file; errno: 13
100215 7:02:24 [ERROR] Can't init databases
100215 7:02:24 [ERROR] Aborting
100215 7:02:24 [Note] /usr/libexec/mysqld: Shutdown complete
100215 07:02:24 mysqld ended
One of my servers was rebooted for some reason and all sites and e-mail accounts were down because the database could not be connected. The first thing I checked was mysqld of course and it was not running. The above was revealed in /var/log/mysqld.log
I was starting to panic and wondered if the server was compromised and I even checked /var/lib/mysql to make sure all the database data was still there.
chown root.root /tmp
chmod 1777 /tmp
And of course be sure that you start MySQL again.
openssl req -new -x509 -nodes -days 1530 -out server.crt -keyout server.key
Using the above, you instantly create a self-signed certificate valid for 1530 days and you can simply skip to step #5.) below.
If You Need a Real SSL Certificate (eg. Equifax/Openssl) then you need to create a CSR request (you'll need to follow Steps 1.) and 2.) in order to create the CSR. You then upload the CSR Certificate to your SSL Provider and they will e-mail you the .crt (SSL Certificate). Remember to keep your key from Step 1, you need the .key and .crt (from your SSL) provider to make use of your certificate.
openssl genrsa -out ssl-private.key 2048
(note above I didn't include the -des3 switch as that makes you choose a passphrase for your key which we don't want).
*Be sure not to lose this key file, especially if you are using the CSR request in Step 2.) to apply for a real SSL certificate
Generating RSA private key, 2048 bit long modulus
e is 65537 (0x10001)
Enter pass phrase for ssl-private.key:
Verifying - Enter pass phrase for ssl-private.key:
openssl req -new -key ssl-private.key -out ssl-request.csr
Enter pass phrase for ssl-private.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [GB]:
State or Province Name (full name) [Berkshire]:
Locality Name (eg, city) [Newbury]:
Organization Name (eg, company) [My Company Ltd]:
Organizational Unit Name (eg, section) :
Common Name (eg, your name or your server's hostname) :
Email Address :
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password :
An optional company name :
mv ssl-private.key ssl-private.key-pass
openssl rsa -in ssl-private.key-pass -out ssl-private.key
Enter pass phrase for ssl-private.key-pass:
writing RSA key
openssl x509 -req -days 730 -in ssl-request.csr -signkey ssl-private.key -out ssl-certificate.crt
unable to load certificate
20243:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:632:Expecting: TRUSTED CERTIFICATE
*(don't forget the -req or you'll get the above error)
cp ssl-private.key ssl.key/server.key
cp ssl-certificate.crt ssl.crt/server.crt
Here is what you should be inside the vhost (obviously be sure that you have the correct path and filenames):
*Remember to restart Apache or the new certificate won't be applied/take effect until you do.
There is actually by default a "Default SSL" vhost that can mess things up for you and can cause surprising and unexpected results.
Default Apache SSL Cert
/etc/httpd/conf.d/ssl.conf there is a default SSL Virtual Host which screws things up by offering itself instead of the SSL cert I specify in my own vhosts