Solaris secure by default initiative!

While perusing the latest Nevada build notes, I came across the following PSARC case:

PSARC case 2004/368 : Secure By Default
BUG/RFE:4875624 *syslogd* turn off UDP listener by default
BUG/RFE:5004374 Ship with remote services disabled by default
BUG/RFE:5016956 By default rpcbind should not listen for remote requests
BUG/RFE:5016975 By default snmpd/dx should not be enabled.
BUG/RFE:5016998 By default inetd should not listen for remote connections.
BUG/RFE:5017041 By default sendmail should not listen for remote connections
BUG/RFE:5046450 Create a greenline profile for Secure by Default installation
BUG/RFE:6267741 RFE: One-touch knob for outbound-only sendmail
BUG/RFE:6414308 syslogd could use some lint soap

I have been bitching about the number of services that come enabled by default for the past ten years, and am SUPER excited to see that Sun finally fixed this annoyance! Nice!

Viewing multipathing information with VMWare ESX Server 3.X

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!

Securing MySQL installations with mysql_secure_installation

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.

-n 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'.

-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.

-n 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.

-n 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.

-n 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.

-n 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.

Displaying Solaris kernel memory usage

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.

Another Comcast service interruption

I am not sure what is happening to Comcast’s IP network as of late, but I am frequently seeing significant packet loss on my cable modem connection:

$ ping www.google.com

PING www.l.google.com (64.233.179.99): 56 data bytes
64 bytes from 64.233.179.99: icmp_seq=14 ttl=238 time=25.527 ms
64 bytes from 64.233.179.99: icmp_seq=15 ttl=238 time=23.751 ms
64 bytes from 64.233.179.99: icmp_seq=17 ttl=238 time=24.669 ms
64 bytes from 64.233.179.99: icmp_seq=20 ttl=238 time=23.855 ms
64 bytes from 64.233.179.99: icmp_seq=23 ttl=238 time=23.442 ms
64 bytes from 64.233.179.99: icmp_seq=26 ttl=238 time=25.103 ms
64 bytes from 64.233.179.99: icmp_seq=27 ttl=238 time=23.294 ms
64 bytes from 64.233.179.99: icmp_seq=28 ttl=238 time=24.033 ms
64 bytes from 64.233.179.99: icmp_seq=32 ttl=238 time=23.458 ms
64 bytes from 64.233.179.99: icmp_seq=34 ttl=238 time=24.503 ms
^C
--- www.l.google.com ping statistics ---
35 packets transmitted, 10 packets received, 71% packet loss
round-trip min/avg/max/stddev = 23.294/24.164/25.527/0.719 ms

I used mtr to verify the packet loss was inside Comcast’s IP network, and am starting to think I need to switch service providers again. Ugh!