I gave a talk on Gluster this evening at our local UNIX users group. I had a good time talking, and enjoyed interacting with everyone that came out. The introduction to Gluster presentation slides are available in the presentation section of my website, and I’ll make sure to get them linked to the users group website. I would like to thank everyone for coming out. I’m truly blessed to have so many awesome friends, and to be able to share information with other admins in the area. Now go forth and Gluster!!
I was reading through the Gluster 3.2.5 release notes today and came across the following blurb:
Red Hat recommends XFS when formatting the disk sub-system. XFS supports metadata journaling, which facilitates quicker crash recovery. The XFS file system can also be de-fragmented and enlarged while mounted and active. Any other POSIX compliant disk file system, such as Ext3, Ext4, ReiserFS may also work, but has not been tested widely.
This is pretty cool, and it’s the first time I recall seeing Redhat recommending XFS over EXT3 or EXT4. Good to know!
I just came across a reference to ZEVO tonight. This appears to be an add-on package for OS X that is built on top of ZFS. I’m going to have to keep an eye on this. Snapshots, data checksumming, de-dup, compression and zfs send/recv would be pretty cool on my Laptop. :)
I’ve learned a number of useful things from the Google learn Python video series. One of the tips I got to use today. That tip was Python’s ability to read a file into a string:
$ cat foo
this
is
a
test
file
of
words
$ python
>>> f = open(“foo”,”r”)
>>> string = f.read()
>>> string
‘this\nis \na \ntest\nfile\nof \nwords\n’
This has a few interesting uses, and I plan to put this to use this weekend when I finish up a Python project I’m working on. I really, really dig Python. It’s quite swell. :)
I started playing with MySQL back in the 4.X days, but never invested a lot of my time since my day job required me to support Oracle databases. I’m trying to branch out more now, and recently picked up a copy of MySQL, MySQL High Availability and PHP And MySQL. There are a slew of things I would like to web-enable, so I’m hoping to learn everything I can about PHP and MySQL in the next few months.
To allow me to start experimenting with PHP and MySQL, I needed to create a test environment. My MySQL environment consists of two CentOS 6 virtual machines running MySQL 5.1.X. Getting MySQL working on these two machines was amazingly easy. First, I installed the mysql packages with yum:
$ yum install mysql mysql-server
Next I started up the MySQL services and made sure they started at boot:
$ chkconfig mysqld on
$ service mysqld start
And finally I secured my MySQL installation by running the mysql_secure_installation script:
$ /usr/bin/mysql_secure_installation
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MySQL
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!
In order to log into MySQL to secure it, we'll need the current
password for the root user. If you've just installed MySQL, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.
Enter current password for root (enter for none):
OK, successfully used password, moving on...
Setting the root password ensures that nobody can log into the MySQL
root user without the proper authorisation.
Set root password? [Y/n] y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!
By default, a MySQL installation has an anonymous user, allowing anyone
to log into MySQL without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.
Remove anonymous users? [Y/n] y
... Success!
Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.
Disallow root login remotely? [Y/n] y
... Success!
By default, MySQL comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.
Remove test database and access to it? [Y/n] y
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!
Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.
Reload privilege tables now? [Y/n] y
... Success!
Cleaning up...
All done! If you've completed all of the above steps, your MySQL
installation should now be secure.
Thanks for using MySQL!
Once this completed I restarted MySQL and could login using the root user (additional accounts will be added in the near future):
$ service mysqld restart
Stopping mysqld: [ OK ]
Starting mysqld: [ OK ]
$ mysql -h localhost -u root –password=XXXXXXXX
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.1.52-log Source distribution
Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2 license
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>
It took me 5 minutes to get MySQL to a state were I could enable replication and create databases. Nice!
Most of my readers utilize SSH keys to access remote systems. The security benefits are well known, and key-based authentication makes automating remote tasks a whole lot easier. When you use key-based authentication it becomes imperative to protect your private key, since a third party could access your systems if they were able to gain access to your account. The SSH key generator (ssh-keygen) will attempt to encrypt your private key by default, and can also be used ssh-keygen to add a password to a private key after the fact.
With passwords comes prompts, and with prompts comes frustration. To alleviate this frustration you can use the ssh-agent process to minimize the number of times you need to type your password. Ssh-agent stores your private keys securely in memory, and hands them out to the ssh process when you attempt to connect to remote systems. Keys are added to ssh-agent through the ssh-add command line utility, which will prompt you for your private key password prior to adding them to the keys held in memory by ssh-agent.
Each time you access a remote system the ssh client will contact the ssh-agent process to acquire your private keys. If you start ssh-agent and run ssh-add to add your private keys when you login to a server, you will now be able to access other hosts using key-based authentication without a password for the length of the shell session. You will find this especially useful when you are using tools like clusterit to manage remote machines.
To automate the process above, I like to modify my bash environment to prompt me for the password when I login to my servers. The ssh-add prompt I get looks similar to this:
$ ssh proxy.prefetch.net
Last login: Tue Jan 17 20:37:54 2012 from 192.168.1.121
Starting an ssh-agent process
Enter passphrase for /home/matty/.ssh/id_dsa:
Identity added: /home/matty/.ssh/id_dsa (/home/matty/.ssh/id_dsa)
Once I’ve input the correct password I can then access other systems freely and without a password. So what exactly did I do to integrate ssh-agent into my shell environment? First I added an exec statement to create an ssh-agent process and make the bash process a child of it (the reasons why this is required are documented in the SSH FAQ):
$ grep ssh-agent .bash_profile
# Start an ssh-agent process and start bash as a child of it
echo “Starting an ssh-agent process”
exec ssh-agent bash
Once ssh-agent is tied into the environment I call ssh-add from my .bashrc to add my private keys:
$ grep ssh-add .bashrc
# Add the encrypted private keys to my in-memory key store with ssh-add.
echo “Calling ssh-add to add my private key to ssh-agent”
ssh-add
The second entry is what causes the following password prompt when I login to my servers:
Enter passphrase for /home/matty/.ssh/id_dsa:
I always try to do everything I can to improve security, and this is definitely one of those every admin should do to protect their beloved private key(s). :) If you are doing something differently, please share your thoughts in the comment section below.
