When fibre channel is used to connect a host to storage, multple paths (e.g. cables) can be used to allow the system to load-balanced fibre channel frames over one or more links. This allows a host to transparently handle link failures, and allows your host to keep chugging along when you perform SAN maintenance or a GBIC or SFP fails. To manage the available fibre channel paths, you need to use a multipathing solution (e.g., Sun’s MPXIO, EMC’s powerpath, or Veritas’ DMP, etc.) on the server. VMWare ESX server comes with it’s own multipathing solution (it is better defined as path failover), and provides the esxcfg-mpath utility to view the path information for all of the targets available on a server:
$ esxcfg-mpath -l
Disk vmhba0:0:0 /dev/sda (70007MB) has 1 paths and policy of Fixed
Local 2:4.0 vmhba0:0:0 On active preferred
Disk vmhba0:1:0 /dev/sdb (70007MB) has 1 paths and policy of Fixed
Local 2:4.0 vmhba0:1:0 On active preferred
Disk vmhba1:0:0 /dev/sdc (51200MB) has 4 paths and policy of Most Recently Used
FC 4:4.0 10000000c9413167<->50060161082006e2 vmhba1:0:0 On active preferred
FC 4:4.0 10000000c9413167<->50060169082006e2 vmhba1:1:0 Standby
FC 4:5.0 10000000c9413168<->50060160082006e2 vmhba2:0:0 On
FC 4:5.0 10000000c9413168<->50060168082006e2 vmhba2:1:0 Standby
Disk vmhba1:0:1 /dev/sdd (51200MB) has 4 paths and policy of Most Recently Used
FC 4:4.0 10000000c9413167<->50060161082006e2 vmhba1:0:1 On active preferred
FC 4:4.0 10000000c9413167<->50060169082006e2 vmhba1:1:1 Standby
FC 4:5.0 10000000c9413168<->50060160082006e2 vmhba2:0:1 On
FC 4:5.0 10000000c9413168<->50060168082006e2 vmhba2:1:1 Standby
You can also retrieve this information from the virtual infrastructure client, but knowing the CLI can be invaluable should a catastrophic failure occur. The more I work with ESX server 3.0, the more I dig it!
MyQSL comes with several utilities to configure and manage a database platform. One useful utility is the mysql_secure_installation script, which limits access to the ‘root’ account, removes the test database, and removes anonymous accounts. To use the mysql_secure_installation script, you can run it with the path to your my.cnf:
$ mysql_secure_installation --defaults =my.cnf
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.
You already have a root password set, so you can safely answer 'n'.
Change the root password? [Y/n]n
... skipping.
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!
The ‘-n’ that is printed looks to be a bug, but reviewing the ‘user’ table indicates that the script worked as expected.
The mdb utility that ships with Solaris 10 is amazing, and allows you to view a wide array of kernel data. Mdb ships with numerous commands (also referred to as dcmds) to view information, and one of my personal favorites is ‘::memstat’:
$ mdb -k
> ::memstat
Page Summary Pages MB %Tot
------------ ---------------- ---------------- ----
Kernel 13834 108 11%
Anon 15663 122 12%
Exec and libs 2040 15 2%
Page cache 7827 61 6%
Free (cachelist) 14248 111 11%
Free (freelist) 75882 592 59%
Total 129494 1011
Physical 127634 997
As you can probably tell by it’s name, memstat displays how a system is using memory, and is typically the first place I look to see how memory is allocated. To see how the kernel is using the memory listed in the ‘::memstat’ output, you can use the ‘::kmastat’ dcmd:
$ mdb -k
> **::kmastat**
cache buf buf buf memory alloc alloc
name size in use total in use succeed fail
------------------------- ------ ------ ------ --------- --------- -----
kmem_magazine_1 16 3371 3556 57344 3371 0
kmem_magazine_3 32 16055 16256 524288 16055 0
kmem_magazine_7 64 29166 29210 1884160 29166 0
kmem_magazine_15 128 6711 6741 876544 6711 0
kmem_magazine_31 256 0 0 0 0 0
kmem_magazine_47 384 0 0 0 0 0
kmem_magazine_63 512 0 0 0 0 0
kmem_magazine_95 768 0 0 0 0 0
kmem_magazine_143 1152 0 0 0 0 0
kmem_slab_cache 56 7204 7250 409600 7204 0
kmem_bufctl_cache 24 33904 34239 827392 33904 0
kmem_bufctl_audit_cache 128 0 0 0 0 0
If you are trying to figure out how mdb works, check out the sample mdb chapter from the next revision of Solaris kernel internals.
Bash is a great shell, and has numerous capabiltiies to make peoples life easier. One super nifty feature is the ability to search through the shell’s history by hitting cntrl-r (control then the letter ‘r’):
$ cntrl-r
(reverse-i-search)`meta’: metastat
Once you locate the command you want to run, you simply hit enter to execute it. Good stuff!
While scouring the Internet last weekend for network testing tools, I came across the super nifty Iperf utility:
http://dast.nlanr.net/Projects/Iperf/
This is a cool utility for testing the TCP/IP stack of a given host, and contains support for IPv6. Nice!