Kernel Wizards (SAM Quest Pt 2)

[SAM TEAM]

Calling all Kernel Wizards...

We need YOUR input to help design a new Kernel Configuration area. If you have a moment, we would greatly appreciate any responses you can give to the following questions:

---------------------------------------------
1. Do you ever configure Dump Devices under Kernel Configuration in SAM? How often?

2. How would you like to access documentation on kernel paramters (Choose your top 3 methods):
a. From the command line
b. A "Help" section within SAM
c. Online web help
d. A book/manual
e. Man pages
f. Other (please specify)

3. HP is considering giving new names to the HP-UX kernel tunable parameters, since the existing names can be confusing. Examples include:
EXISTING NAME -----> NEW NAME
-------------------------------
a. maxuprc ---> max_processes_per_user
b. semmns ---> max_sysV_semaphores
c. hfs_max_ra_blocks -->
max_readahead_blocks_on_hfs

Of course, the existing names will continue to work, as aliases for the new names. Error messages and documentation will give both names.

Do you think we should give tunables new names like these? Why or why not? Do you have suggestions on how the new names should be chosen?

4. The Kernel Configuration area in SAM is going to change. It will have a CLI and a GUI (or a web interface). Tell us what type of CLI works best for YOU:

- A SINGLE command OR
- SEVERAL different commands with fewer options

(If you prefer SEVERAL commands, which of the following features should be grouped together?
a. Set kernel parameters
b. View a change log for kernel parameters
c. Provide data to diagnose kernel parameter problems
d. Set thresholds/Generate notifications when you reach kernel parameter limits
e. Define groups/values of kernel parameters and deploy them on other systems
f. Include/Exclude device drivers and other kernel modules from the built kernel
g. Display documentation on kernel parameters

---------------------------------------------

THANK YOU for your input! This helps us design a better product for YOU! :)

[Tracey · Accepted solution]

1. When I build a machine only. I've never reconfigured.
2. b. A "Help" section within SAM
e. Man pages
c. On-Line Web help
3. I like the new names, easier to remember!
4. Single

[Bruce Regittko_1]

Hi,

1. Almost never and then with the command line.

2. Command line, man page, book/manual (in no partictular order)

3. I like the idea of the more descriptive names. The maxusers parameter could really use a more descriptive name.

4. I prefer a CLI with many simple commands rather than few complex commands. Your grouping suggestions are good.

--Bruce

[John Bolene]

1. no
2. b help section, f html pages, for that matter, man pages are much better served thru html web pages (I used man2html and have my own server that is searchable)

3. make it so, the old ones are too cryptic

4. I would have to see the various ways to choose.

[Patrick Wallek]

1. Dump Devices under SAM - Once in a blue moon. Only when a machine configuration changes and makes such a change necessary.

2. Access kernel parm. docs - Top 3 in order - C, D, B

3. New names - I LIKE the new names scenario. More descriptive names are MUCH better.

4. I would prefer a GUI, like currently through SAM, or a web interface.

If command line is necessary I would group:
group 1 - a b f g
group 2 - c
group 3 - d
group 4 - e

[Alan Riggs]

1. Do you ever configure Dump Devices under Kernel Configuration in SAM? How often?

Never. I use the command line.

2. How would you like to access documentation on kernel paramters (Choose your top 3 methods):
a. From the command line
e. Man pages
b. A "Help" section within SAM

3. HP is considering giving new names to the HP-UX kernel tunable parameters, since the existing names can be confusing.

Please don't. The new names seem of little value:

(1)They might encourage folks to tune the kernel without doing further.
(2)They risk confusing with any number of extant documents, procedures and recommendations both from HP and other vendors.
(3)If at any point the "aliases" become unsupported, old scripts, tools, and monitors might cease functioning properly.
(4)The increased information provided by the more unwieldy names is minimal.

4. The Kernel Configuration area in SAM is going to change. It will have a CLI and a GUI (or a web interface). Tell us what type of CLI works best for YOU:

SEVERAL different commands with fewer options. Grouped as follows:

a. Set kernel parameters
b. View a change log for kernel parameters
g. Display documentation on kernel parameters
f. Include/Exclude device drivers and other kernel modules from the built kernel

c. Provide data to diagnose kernel parameter problems
d. Set thresholds/Generate notifications when you reach kernel parameter limits

e. Define groups/values of kernel parameters and deploy them on other systems

[James R. Ferguson]

Hi!

1: I only configure dump devices only when setting up a new machine or cold-installing.

2. Kernel parameter documentation in man pages, on the web, and built into SAM (as currently, but expanded) are all very desirable and have value for different tasks.

3. Do *not* invent new names even if you retain the old ones! In my opinion this could become confusing and run counter to effective documentation and communication as translations between the aliases are necessitated. As *new* parameters are added, then attempt to choose names that provide logical grouping, as for instance, 'vx_" for parameters related to VxFS file systems.

4. I would like to see more of the proposed structure before commenting in detail. I like the idea of generating threshold notifications. I assume that this would be user-configurable in the new interface. Since 'kmtune' exists, I don't necessarily see the need for a command level interface, and think that SAM should remain as the GUI. Rather than a change log, I'd like to see the ability to view all parameters that differ from their defaults, including perhaps, by default template. A potentially nice feature would be advisory messages of the cross-impact of changing interrelated parameters as configuration values are chosen.

...JRF...

[Karthik_2]

---------------------------------------------
1. Do you ever configure Dump Devices under Kernel Configuration in SAM? How often?
No I have not configured dump devices through sam .Dump devices are configured only during the install

2. How would you like to access documentation on kernel paramters (Choose your top 3 methods):
a.A pocket book sized manual
b.command line
c. A "Help" section within SAM

3. HP is considering giving new names to the HP-UX kernel tunable parameters, since the existing names can be confusing. Examples include:
EXISTING NAME -----> NEW NAME
-------------------------------
a. maxuprc ---> max_processes_per_user
b. semmns ---> max_sysV_semaphores
c. hfs_max_ra_blocks -->
max_readahead_blocks_on_hfs

This is a good idea provided we have the alias names as you are aware these names are used in the doc of other software vendors like oracle
The names being descriptive help us to understand what we are trying to change and what wea are doing is *sane*

4. The Kernel Configuration area in SAM is going to change. It will have a CLI and a GUI (or a web interface). Tell us what type of CLI works best for YOU:

A family of commands like the lv and vg family.
But this should not exceed 4 or 5
*set
*get
*log ...help ...tuned kernel sets..preview etc..
*Another nice option would be a command which recommends you to tune the kernel

Cheers
Karthik...

[Michael Lee_4]

1.only once
2.c. On-Line Web help
3.old names are ok----when we change parameters, we consider it carefully and look it up on manuls, not by its name.
4.I hope it will be a wizard.

[Steven Sim Kok Leong]

Hi,

1. Do you ever configure Dump Devices under Kernel Configuration in SAM? How often?

Extremely rarely, and I used the command line instead ie. lvlnboot -d.

2. How would you like to access documentation on kernel paramters (Choose your top 3 methods):
a. From the command line
b. A "Help" section within SAM
c. Online web help
d. A book/manual
e. Man pages
f. Other (please specify)

f.
- a searchable help section
- a printable manual
- a hierarchical chart
- a highlight on parameters modified
- allow network parameters to be modified as well as detailed usage help for them

Justifications
- A search facility is good for searching for the required kernel parameters.

- A tree hierachy would be useful in interpreting dependencies eg.

- I recalled a few years back that the X-windows based SAM has very detailed on-line help for kernel parameters. However, I had to select help for each kernel parameter and send them to the printer to allow a browsable hardcopy.

ninode
|-> nproc -> maxusers
|-> maxusers
|-> npty

- by providing a highlight on items modified, if maxusers is modified, I can tell from SAM easily the new values for nproc etc from the highlight.

- network parameters (both supported and unsupported) along with detailed usage. The help on tcp_discon_by_addr was not very helpful at all from ndd, by itself.

3. HP is considering giving new names to the HP-UX kernel tunable parameters, since the existing names can be confusing. Examples include:
EXISTING NAME -----> NEW NAME
-------------------------------
a. maxuprc ---> max_processes_per_user
b. semmns ---> max_sysV_semaphores
c. hfs_max_ra_blocks -->
max_readahead_blocks_on_hfs

Of course, the existing names will continue to work, as aliases for the new names. Error messages and documentation will give both names.

Do you think we should give tunables new names like these? Why or why not? Do you have suggestions on how the new names should be chosen?

I would not recommend having new names, it brings confusion, and more things to remember. If my boss refers to the alias, I have to remember to correlate the alias to the actual.

No new names should be chosen. Detailed help would be fine. By having aliases, you are asking ISVs (SAP, Oracle) to modify their manuals accordingly.

4. The Kernel Configuration area in SAM is going to change. It will have a CLI and a GUI (or a web interface). Tell us what type of CLI works best for YOU:

- A SINGLE command OR
- SEVERAL different commands with fewer options

If there is not going to be too many options, I would prefer one SINGLE command with different options. If however there are too many options, I would prefer the commands to be segregated.

Hope this helps. Regards.

Steven Sim Kok Leong
Brainbench MVP for Unix Admin
http://www.brainbench.com