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!
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.
-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]
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
-n Remove anonymous users? [Y/n]
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]
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]
- Dropping test database...
- Removing privileges on test database...
Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.
-n Reload privilege tables now? [Y/n]
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
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
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’):
Once you locate the command you want to run, you simply hit enter to execute it. Good stuff!
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 (126.96.36.199): 56 data bytes
64 bytes from 188.8.131.52: icmp_seq=14 ttl=238 time=25.527 ms
64 bytes from 184.108.40.206: icmp_seq=15 ttl=238 time=23.751 ms
64 bytes from 220.127.116.11: icmp_seq=17 ttl=238 time=24.669 ms
64 bytes from 18.104.22.168: icmp_seq=20 ttl=238 time=23.855 ms
64 bytes from 22.214.171.124: icmp_seq=23 ttl=238 time=23.442 ms
64 bytes from 126.96.36.199: icmp_seq=26 ttl=238 time=25.103 ms
64 bytes from 188.8.131.52: icmp_seq=27 ttl=238 time=23.294 ms
64 bytes from 184.108.40.206: icmp_seq=28 ttl=238 time=24.033 ms
64 bytes from 220.127.116.11: icmp_seq=32 ttl=238 time=23.458 ms
64 bytes from 18.104.22.168: icmp_seq=34 ttl=238 time=24.503 ms
--- 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!