SMF is one of the new features in Solaris 10, and provides the infrastructure needed to start and stop all of the processes that make up a useful system. SMF maintains a repository to store a variety of meta data to describe a service, and this information includes the state of a given service. The state of a service can be enabled if the service is supposed to start when the system boots, or disabled if the service isn’t supposed to start when the system boots. I am a big fan of disabling every service that isn’t needed to make the server perform it’s function, and this is one area where I think SMF shines. Once I get all of the services on a Solaris 10 host configured the way I want them, I use the svccfg “extract” option to dump the service information to a site manifest:
$ svccfg extract > site.xml
After I create this manifest, I use the svccfg “apply” option to apply it to other servers:
$ <strong>svccfg apply site.xml<strong>
This is rather useful, and sure beats creating a script to do a bunch of mv SXXX to sXXXX. Nice!
Solaris has been a 64-bit operating system for longer than I can recall. In addition to supporting 64-bit applications, Solaris also supports 32-bit applications, and is capable of running as a 32-bit entity on 32-bit platforms. If you need to see if 32- or 64-bit applications are supported on a given platform, you can run isainfo with the “-v” option:
$ isainfo -v
64-bit sparcv9 applications
vis
32-bit sparc applications
vis v8plus div32 mul32
If you would like to see which hardware capabilities (e.g., MMX extensions) are available, you can run isalist:
$ isalist
pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86
If you are curious what the optimal instruction set is for your platform, you can run optisa with the output of isalist as the argument:
$ optisaisalist``
pentium_pro+mmx
Tis all about knowing what your platform is capable of!
While perusing my BIND query logs, I came across the following entry:
Nov 21 12:34:41 dns named[780]: [ID 866145 local0.info] client
1.2.3.4#32773: query: yikes.com IN MX -E
All of the text up to the record type (MX in this case) made sense, but I had no idea what the “-E” meant. Being the curious person I am, I dug through the BIND source code to locate the logging code. After a couple of find statements, I was able to locate the logging code in query.c:
ns_client_log(client, NS_LOGCATEGORY_QUERIES, NS_LOGMODULE_QUERY,
level, "query: %s %s %s %s%s%s", namebuf, classname,
typename, WANTRECURSION(client) ? "+" : "-",
(client->signer != NULL) ? "S": "",
(client->opt != NULL) ? "E" : "");
So a “+” or “-” in a query log entry indicates that a client requested recursion, and the “E” means that the query requested EDNS0. I would like to thank Knobee for his feedback on this post.
I recently needed to locate the value of a specific symbol in the .data segment of an ELF executable. Prior to learning that mdb and gdb could be used to perform this lookup, I typically did the following:
This seemed tedious, so I asked around to see if there was an easier way. It turns out I was overcomplicating this, as mdb and gdb can be used to resolve the symbol for me. Here is how to use mdb to display the value of the symbol mod_log_forensic in the library mod_log_forensic.so:
$ mdb mod_log_forensic.so
> ::nm
Value Size Type Bind Other Shndx Name
0x00000000|0x00000000|NOTY |LOCL |0x0 |UNDEF |
0x00000000|0x00000000|FILE |LOCL |0x0 |ABS |.libs/mod_log_forensic.so
0x000000b4|0x00000000|SECT |LOCL |0x0 |1 |
0x0000019c|0x00000000|SECT |LOCL |0x0 |2 |
0x0000034c|0x00000000|SECT |LOCL |0x0 |3 |
0x000004f4|0x00000000|SECT |LOCL |0x0 |4 |
0x00000514|0x00000000|SECT |LOCL |0x0 |5 |
0x0000067c|0x00000000|SECT |LOCL |0x0 |6 |
0x000006b8|0x00000000|SECT |LOCL |0x0 |7 |
0x000006e8|0x00000000|SECT |LOCL |0x0 |8 |
0x000007cc|0x00000000|SECT |LOCL |0x0 |9 |
0x00000ff8|0x00000000|SECT |LOCL |0x0 |10 |
0x000010f8|0x00000000|SECT |LOCL |0x0 |11 |
0x00011308|0x00000000|SECT |LOCL |0x0 |12 |
0x00011384|0x00000000|SECT |LOCL |0x0 |13 |
0x0001149c|0x00000000|SECT |LOCL |0x0 |14 |
0x00011554|0x00000000|SECT |LOCL |0x0 |15 |
0x0001158c|0x00000000|SECT |LOCL |0x0 |16 |
0x000115c4|0x00000000|SECT |LOCL |0x0 |17 |
0x000115ca|0x00000000|SECT |LOCL |0x0 |18 |
0x00000000|0x00000000|SECT |LOCL |0x0 |19 |
0x00000000|0x00000000|SECT |LOCL |0x0 |20 |
0x00000000|0x00000000|SECT |LOCL |0x0 |1 |
0x00000000|0x00000000|SECT |LOCL |0x0 |21 |
0x00000000|0x00000000|SECT |LOCL |0x0 |22 |
0x00000000|0x00000000|SECT |LOCL |0x0 |1 |
0x000115ca|0x00000000|OBJT |LOCL |0x0 |18 |_END_
0x00000000|0x00000000|OBJT |LOCL |0x0 |1 |_START_
0x00000000|0x00000000|FILE |LOCL |0x0 |ABS |mod_log_forensic.c
0x000115ca|0x00000000|NOTY |LOCL |0x0 |18 |Bbss.bss
0x00011554|0x00000000|NOTY |LOCL |0x0 |15 |Ddata.data
0x00000ff8|0x00000000|NOTY |LOCL |0x0 |10 |Drodata.rodata
0x0001158c|0x00000000|NOTY |LOCL |0x0 |16 |Dpicdata.picdata
0x00000ff8|0x00000100|OBJT |LOCL |0x0 |10 |test_char_table
0x000010f8|0x00000000|NOTY |LOCL |0x0 |11 |.L1334
0x0000110c|0x00000000|NOTY |LOCL |0x0 |11 |.L1335
0x00001130|0x00000000|NOTY |LOCL |0x0 |11 |.L1339
0x00001144|0x00000000|NOTY |LOCL |0x0 |11 |.L1340
0x0000116c|0x00000000|NOTY |LOCL |0x0 |11 |.L1366
0x00001174|0x00000000|NOTY |LOCL |0x0 |11 |.L1367
0x00001188|0x00000000|NOTY |LOCL |0x0 |11 |.L1373
0x00001190|0x00000000|NOTY |LOCL |0x0 |11 |.L1374
0x000011a4|0x00000000|NOTY |LOCL |0x0 |11 |.L1375
0x000011ac|0x00000000|NOTY |LOCL |0x0 |11 |.L1380
0x000011b4|0x00000000|NOTY |LOCL |0x0 |11 |.L1381
0x000011c8|0x00000000|NOTY |LOCL |0x0 |11 |.L1417
0x000011d4|0x00000000|NOTY |LOCL |0x0 |11 |.L1419
0x000011e8|0x00000000|NOTY |LOCL |0x0 |11 |.L1420
0x0000121c|0x00000000|NOTY |LOCL |0x0 |11 |.L1424
0x0000122c|0x00000000|NOTY |LOCL |0x0 |11 |.L1425
0x00001240|0x00000000|NOTY |LOCL |0x0 |11 |.L1430
0x00001264|0x00000000|NOTY |LOCL |0x0 |11 |.L1431
0x00001278|0x00000000|NOTY |LOCL |0x0 |11 |.L1432
0x000115c8|0x00000000|NOTY |LOCL |0x0 |17 |.L1442
0x00001284|0x00000000|NOTY |LOCL |0x0 |11 |.L1447
0x000012a0|0x00000000|NOTY |LOCL |0x0 |11 |.L1448
0x0001158c|0x00000030|OBJT |LOCL |0x0 |16 |forensic_log_cmds
0x00000f38|0x00000044|FUNC |LOCL |0x0 |9 |set_forensic_log
0x000115bc|0x00000000|OBJT |LOCL |0x0 |16 |.L1464
0x000007cc|0x0000002c|FUNC |LOCL |0x0 |9 |make_forensic_log_scfg
0x000007f8|0x00000054|FUNC |LOCL |0x0 |9 |merge_forensic_log_scfg
0x00000f7c|0x0000007c|FUNC |LOCL |0x0 |9 |register_hooks
0x0000084c|0x00000140|FUNC |LOCL |0x0 |9 |open_log
0x0000098c|0x00000040|FUNC |LOCL |0x0 |9 |log_init
0x000009cc|0x00000128|FUNC |LOCL |0x0 |9 |log_escape
0x00000af4|0x0000006c|FUNC |LOCL |0x0 |9 |count_string
0x00000b60|0x00000034|FUNC |LOCL |0x0 |9 |count_headers
0x00000b94|0x00000060|FUNC |LOCL |0x0 |9 |log_headers
0x00000bf4|0x00000270|FUNC |LOCL |0x0 |9 |log_before
0x00000e64|0x000000d4|FUNC |LOCL |0x0 |9 |log_after
0x00011384|0x00000000|OBJT |GLOB |0x0 |13 |_PROCEDURE_LINKAGE_TABLE_
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |apr_table_get
0x0001149c|0x00000000|OBJT |GLOB |0x0 |14 |_DYNAMIC
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |apr_file_open
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |ap_hook_log_transaction
0x000115ca|0x00000000|OBJT |GLOB |0x0 |17 |_edata
0x00001307|0x00000000|OBJT |GLOB |0x0 |11 |_etext
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |apr_pstrcat
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |ap_server_root_relative
0x00011308|0x00000000|OBJT |GLOB |0x0 |12 |_GLOBAL_OFFSET_TABLE_
0x00011554|0x00000038|OBJT |GLOB |0x0 |15 |log_forensic_module
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |apr_table_do
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |apr_palloc
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |ap_log_assert
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |apr_pstrdup
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |strlen
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |strcpy
0x000115ca|0x00000000|OBJT |GLOB |0x0 |18 |_end
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |memset
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |sprintf
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |ap_hook_post_read_request
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |ap_open_piped_log
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |ap_log_error
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |ap_hook_open_logs
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |apr_table_setn
0x00000000|0x00000000|FUNC |GLOB |0x0 |UNDEF |apr_file_write
> log_forensic_module/D
mod_log_forensic.so`log_forensic_module:
mod_log_forensic.so`log_forensic_module: 20020903
> $q
It’s all about simplifying your IT life. :)
While reviewing some notes last night, I came across an entry in my notebook that described how to configure Solaris interfaces to support 802.1Q tagged queing. Given a physical interface named “ce0” that will be associated with VLAN 500, the formula to create the interface would be:
ce + (VLAN number * 1000 + instance number)
So in the example above, you would use an interface named ce500000 to tell the host to process 802.1Q tagged Ethernet frames destined for VLAN 500. I am still not sure why Sun chose to use this format, since you can’t just look at a name and know what it is. Luckily this annoyance will be fixed when the clearview project integrates into Solaris (clearview will allow you to use vanity names with interfaces).