OpenVOS Blog

Showing archives for category Availability

Considering an “atomic clock”?

7.4.2014AvailabilityBy: Recently, a customer wrote to Stratus Customer Service to ask whether we could recommend an “atomic clock” for use with his OpenVOS system. It seems that this customer does not have access to an NTP (Network Time Protocol) server, and so wanted to use a stand-alone equivalent. In theory, any product that supports the NTP protocol should be compatible with VOS or OpenVOS. But is always good to hear of a success story and know that a specific product meets the needs of an existing customer.

We surveyed our customers and found a long-time OpenVOS customer who was using a “Sonoma D12 Network Time Server”, which uses CDMA and GPS technologies to maintain an accurate indication of the time. If you are using this device, or some other device, to handle your NTP duties, please let us know in the comments below.

 

New password encryption algorithms are coming!

6.24.2014AvailabilityBy: Starting in OpenVOS Release 18.0, VOS System Administrators will be able to select one of 3 new password encryption algorithms. This post provides an overview of these changes.

Read More

Security Updates for Open-Source Software

6.20.2014AvailabilityBy: I was recently asked why Stratus was not providing security updates for customers running OpenSSL on releases of VOS prior to 17.0, when we are still providing updates to customers running OpenSSL on VOS 14.7 on Continuum. On the face of it, this seems like an inconsistent policy. Since OpenSSL is one of the most security-sensitive products that we offer for the VOS operating system, it is important to understand how we manage it.

Read More

Using a modern copier as a line printer

8.23.2013AvailabilityBy: Does your office have a modern photocopier? One that accepts output via TCP/IP? If so, you can probably configure the OpenVOS spooler to send files to it. Here’s how.

Read More

How much disk storage can a single VOS module handle?

8.15.2013AvailabilityBy: Today, a customer asked me how much disk storage a single VOS module can address. Here is my response.

The per-disk (actually, per LUN) storage limit for all V Series releases is 8.7 TB. A single VOS module supports a maximum of 256 LUNs. Therefore, the VOS software limit for total storage on a single module is 256 * 8.7T, which is 2.2 Petabytes (1 Petabyte equals 1000 Terabytes).

Now, consider the hardware limit. A single 2nd-generation ftScalable Storage array can support 72 drives. The largest drive that VOS currently supports is 300 GB. Therefore, the VOS hardware limit on a single module is 72 drives * 300 GB, which is 21.6 TB.  This calculation assumes NRAID at the ftScalable Storage level, with duplexing at the VOS level.

Thus, the current maximum hardware configuration can support about 1% of the maximum software configuration. That’s okay; we want the software limits to be a lot higher than the hardware limits, because the software limits are a lot harder to change. 

Larger disk drives for 2nd-generation ftScalable Storage are on the way. It is likely that the next drive will have a capacity of 600GB. That drive will increase the hardware storage limit to 43TB.

In theory, VOS can also support additional RAID arrays, but we’ve never had a customer request it.

Note: Any POSIX code that uses huge LUNs must be built with either the _VOS_LARGE_INODE macro defined, or with one of the “large file” macros defined. This is because inode numbers on these huge LUNs require 64 bits of data. Our own layered products are built with this support enabled.

If you think your VOS-based application needs more storage than Stratus currently offers, please let us know your of your plans as far in advance as possible. We’ll work with you to craft a solution you can use.

Fix the algorithm before you fix the code

7.29.2013AvailabilityBy: When you are fixing bugs in existing code, it is easy to fall into the habit of finding the “mistake” in the code and adjusting the code to avoid the mistake. But if the root cause of the problem was a design error, or a problem with the algorithm, then just adding another flag or goto statement in the code is the wrong approach. Not only have you left the the root cause intact, but now you have made the code harder to understand for the next software engineer who has to figure it out.

Train yourself to ask “how would I have solved this problem if I was the original coder?” Then look at the difference between the “clean sheet of paper” approach and the one that is actually there in front of you. But be pragmatic. I’m certainly not suggesting that you should reimplement a function because you and the author have a different approach. Take this step as a thought experiment. You have a test case that fails. The author missed this case. What led her to miss this case? If the author had known about this case, how would her approach have been different? These types of questions are invaluable when digging into code that basically works, but still has some bugs.

In our case, instead of adding another parameter to an internal function, and adding another automatic variable that had to be correctly initialized at 3 different entrypoints to the main procedure, and adding code to test this new variable at a critical point, I realized we could repair the algorithm by changing the order in which the sub-steps were performed. Once we did that, the need for additional variables and special cases disappeared. The final code is actually much easier to understand than the original code, to say nothing of the first attempt at a repair. This gives me confidence that we are on the right track. The test case that reproduces the problem proved that both the original (overly complex) fix, and the revised (simplified) fix solve the problem. Now we just need to be certain that we didn’t break anything else.

Since this fix is headed to a field release (i.e., one that is already installed at customer locations), we will also be running three types of intensive regression tests. Two of them will check for continued adherence to the POSIX standard (the bug fix is in code that implements a POSIX function), and the third type of test is a general system-level regression tests.

Fix the algorithm first. Once the algorithm is correct, deal with the code.

Potential enhancements to OpenVOS

7.19.2013AvailabilityBy: Here is a short list of useful enhancements to OpenVOS that have been suggested by our customers. I’m interested in learning which of these ideas you think would be the most useful to you and your organization. I can’t promise that we will implement any of them, but knowing the relative popularity of them would be helpful to me as I evaluate them. This list is not in any particular order at the moment.

  • set command_status nonzero when display -match fails to find a match.
  • have a way to truncate the output of attach_default_output at a specified line width.
  • teach the system to automatically change time zones twice a year.
  • allow an unprivileged user to run the unbundle command macro with the -keep_dates argument.
  • add a command function to return or query a set of command/object/include library pathnames.
  • protect system log files from accidental modification (at a minimum, remove write permission after no longer in use).
  • enhance the audit entries in the security log to include the IP address of telnet/ssh sessions (now is just a random name).
  • allow system administrators to set a per-user account expiration date.

So, please add your comments. Please pick the ones you like and rank them from most-useful to least-useful. You can skip the ones you don’t need.

If you have additional suggestions beyond this list, that’s ok too. Just be sure to explain it in a way that I can understand it!

Inconsistent success using public keys

6.3.2013AvailabilityBy: Why is it that from my home directory I can use SSH with public key authentication to log into another host without being prompted for a password?

Read More

OpenVOS Release 17.2.0 is generally available!

4.25.2013AvailabilityBy: I’m pleased to announce that OpenVOS Release 17.2.0, GNU Tools Release 4.0.0 and Kona for OpenVOS Release 1.1.0 are now generally available.  All VOS V Series customers with a maintenance contract are eligible for these releases. Plus, all of them are available on the www.openvos.com web site, so you no longer need to order release tapes.

StrataDoc (stratadoc.stratus.com) has been updated with the manuals for these products as well.

What’s in OpenVOS 17.2, you ask?  Here is a brief summary:

  • Support for a new LTO-5 tape drive (up to 1.5TB capacity)
  • Support for Solid State Disk Drives in ftScalable Gen2
  • Support for 64-bit Stream Files
  • Support for Extended Names Version 2
  • Phase 1 of Improved Password Encryption
  • Increased Software Limits
  • Larger Syserr and Accounting Logs
  • Sort Command Performance Boost (sorts more records in memory)

Here is what is new in GNU Tools 4.0:

  • Support for 64-bit Stream Files and Extended Names V2
  • New Porting Bases for Many Open-Source Packages
  • Man Pages for Most Packages
  • The wget command
  • The xz command
  • GDB can follow forks

Here is what is new in Kona 1.1:

  • Support for 64-bit Stream Files and Extended Names V2
  • All Relevant OpenJDK Tests Pass

OpenVOS Release 17.2.0 supports all current V Series hardware platforms (V100 to V6512). It will be the final release to support the V100, V150, V200, V250, V300, V400, and V500 platforms.

See the Software Release Bulletins for these products, available on StrataDOC, for more details.

 

 

 

Remote Command Execution

4.24.2013AvailabilityBy: Last week (well it was last week when I started writing this) we had an issue come into the CAC where someone wanted to write a command macro that ran telnet to log into a system and execute some commands, for example the command macro test.cm logins into a remote host and executes the foo.cm command macro.

&attach_input                                                                 
telnet 192.168.77.128
password
foo.cm

Figure 1 – telnet command macro test.cm

display_line display_system_usage                                             
display_system_usage
display_line netstat -statistics -protocol tcp
netstat -statistics
display_line analyze_system -request_line 'stcp_meters -all -long' -quit
analyze_system -request_line 'stcp_meters' -quit

Figure 2 – foo.cm

 

Unfortunately telnet is not designed to execute in a command macro and it fails.

test                                                                          
telnet: fatal error - tcgetattr failed
Error on line 3 of test.
command_processor: Object not found. password. In command macro
     %azvos#m17_mas>SysAdmin>Noah_Davids>test.cm

Figure 3 – execution of test.cm fails

 

There are however several ways that automagic login into a remote host followed by command execution can be done.

send_cmds.c:

I wrote a program a while back that makes a connection to a telnet server, sends strings, and parses the output. The scripting language is simple but for simple things it works fine. The source code with more extensive examples can be found here

The script is basically a send string followed by a wait string. The script advances to the next line when the wait string is seen, as I said very simple. The script does have arguments, in figure 4 I use arg0 for the password so my password is not stored in the script. Execution of the script follows in figure 5. I truncated the output of each command in the interest of saving space. You will notice that the non-control characters from the character positioning strings are displayed until I set the terminal type to ascii.

//login                                                                         
/login nd/Password?
/arg0/ready
/set_terminal_parameters -terminal_type ascii -pause_lines 0/ready
/foo.cm/ready
/quit/quit

Figure 4 – send_cmds script to login and execute the foo command macro

send_cmds -IPAddress 192.168.77.128 -InputFilePath test.send_cmds -no_Verbose -a
+rg0 password

       PHOENIX CAC VOS TEST SYSTEM (%phx_vos#m16)

   *** To boot on a different VOS Release see     ***
   *** >Overseer>COMMON>cfg>reconfig_instructions ***

OpenVOS Release 17.1.0ax, Module %phx_vos#m16
Please login  08:15:01
login nd
Password?
Noah_Davids.CAC logged in on %phx_vos#m16 at 13-04-21 08:15:01 mst.
[f[J[?7l[20l=[1m[1;24r[f[J[J[24;80f
[0;1mready  08:15:01
[0mset_terminal_parameters -terminal_type ascii -pause_lines 0
[1mset_terminal_parameters -terminal_type ascii -pause_lines 0

ready  08:15:01
foo.cm
display_system_usage
Usage statistics for module %phx_vos#m16, G94330, OpenVOS Release 17.1.0ax
All 762.6 hours (31.7 days) up.
----CPU-----         Last Min     Last 5 Min       Last Hour      All Up Time
. . . . .
Int. Time           0.00  0.1%     0.02  0.1%      0.23  0.1%     191.65  0.1%
netstat -statistics
tcp:
. . . . 
       201766  tcpOutRsts

analyze_system -request_line stcp_meters -all -long -quit
OpenVOS Release 17.1.0ax, analyze_system Release 17.1.0ax
Current process is 884, ptep 8D3E6000, Noah_Davids.CAC

stcp_meters   %phx_vos#m16                762:36:19     13-04-21 08:15:02
 . . . .
   bufdat executed                             678 (avg 0.0002/sec)

ready  08:15:02
ready  08:15:03

Figure 5 – send_cmds execution

 

expect:

There is a program called expect in the gnu_library. The syntax for an expect script can be very complex, it allows for branching based on different return strings so you can intelligently handle errors instead of just timing out. You can check out the web for examples, just search for “expect script examples”. I will present a simple script that just logs in and executes the foo.cm macro. Note that there were some bugs in early versions of gnu_tools (which is why I wrote send_cmds) but as of release 3.4.0a you should be OK. While I do not show it, expect can also use arguments so the password does not have to be part of the script or the script can prompt you for a password. Again I truncated the command output from the script and you can see that the non-control characters from the character positioning strings are displayed until I set the terminal type to ascii. Expect however filters the string differently so not all the characters are shown.

spawn "telnet"                                                                
expect "telnet>"
send "open 192.168.77.128r"
expect "login"
send "login ndr"
expect "Password"
send "passwordr"
expect "ready"
send "set_terminal_parameters -terminal_type ascii -pause_lines 0r"
expect "ready"
send "foo.cmr"
expect "ready"

Figure 6 – expect script to login and execute the foo command macro

>bin>expect test.expect
spawn telnet
telnet> open 192.168.77.128
Trying...
Connected to 192.168.77.128.
Escape character is '^]'.


       PHOENIX CAC VOS TEST SYSTEM (%phx_vos#m16)

   *** To boot on a different VOS Release see     ***
   *** >Overseer>COMMON>cfg>reconfig_instructions ***

OpenVOS Release 17.1.0ax, Module %phx_vos#m16
Please login  08:51:28
login nd
Password?

Noah_Davids.CAC logged in on %phx_vos#m16 at 13-04-21 08:51:28 mst.
fJ?7l20l
0;1mready  08:51:28
1mset_terminal_parameters -terminal_type ascii -pause_lines 0
ready  08:51:28
foo.cm
display_system_usage
Usage statistics for module %phx_vos#m16, G94330, OpenVOS Release 17.1.0ax
All 763.2 hours (31.8 days) up.

----CPU-----         Last Min     Last 5 Min       Last Hour      All Up Time
. . . .
Int. Time           0.00  0.1%     0.02  0.1%      0.24  0.1%     191.80  0.1%
netstat -statistics
tcp:
. . . .
       201926  tcpOutRsts

analyze_system -request_line stcp_meters -all -long -quit
OpenVOS Release 17.1.0ax, analyze_system Release 17.1.0ax
Current process is 895, ptep 8D2E1200, Noah_Davids.CAC

stcp_meters   %phx_vos#m16                763:12:46     13-04-21 08:51:29
. . . .
   bufdat executed                             678 (avg 0.0002/sec)

ready  08:51:29
ready  08:51:29

Figure 7 – expect script execution

 

SSH:

Finally you can use SSH to execute a command on a remote system. If you have also set up public key authentication you are not prompted for a password at the time of execution.

There are a number of interesting wrinkles when using SSH. First abbreviations do not work, don’t try to execute dps, use display_print_status.

ssh nd@192.168.77.128 dbs                                                     
sh: dbs: command not found
ready  12:26:25

Figure 8 – Using SSH to remotely execute a command abbreviation doesn’t work

ssh nd@192.168.77.128 display_batch_status                                    

Batch queues for %phx_vos#m16

QUEUE                    STATE   MAX           RUNNING JOBS
normal                    run      5
ready  12:26:43

Figure 9 – Using SSH to remotely execute a command does work

 

Second, executing a command macro directly doesn’t work; note there is no output and it appears that only the first command in the macro was even processed.

ssh nd@192.168.77.128 'foo.cm'                                                
display_system_usage
ready  12:08:40

Figure 10 – Using SSH to remotely execute a command macro doesn’t always work

 

Instead you have to execute the shell command and provide the command macro as its argument.

ssh nd@192.168.77.128 '/bin/sh foo.cm'
display_system_usage
Usage statistics for module %phx_vos#m16, G94330, OpenVOS Release 17.1.0ax
All 766.5 hours (31.9 days) up.

----CPU-----         Last Min     Last 5 Min       Last Hour      All Up Time
CPU minutes         0.02  0.5%     0.09  0.4%      0.91  0.4%     724.76  0.4%
. . . .
Int. Time           0.00  0.1%     0.02  0.1%      0.23  0.1%     192.57  0.1%
netstat -statistics
tcp:
. . . .
       202796  tcpOutRsts

analyze_system -request_line stcp_meters -all -long -quit
OpenVOS Release 17.1.0ax, analyze_system Release 17.1.0ax
Current process is 922, ptep 8D3C2780, Noah_Davids.CAC

stcp_meters   %phx_vos#m16                766:30:14     13-04-21 12:08:57
. . . .
   bufdat executed                             678 (avg 0.0002/sec)

ready  12:08:59

Figure 11 – Using SSH to remotely execute a command macro by executing it as a shell script

 

Complex macros will not work. For example each line of the command macro is forked as a separate process so macros that use the process_dir to hold intermediate results will not work. Note that each invocation of analyze_system is reporting a different process number.

ssh nd@192.168.77.128 '/bin/sh foo3.cm'                                       

%phx_vos#m16_mas>SysAdmin>Noah_Davids>foo3.cm  13-04-21 12:52:20 mst

display foo3.cm
display_line
analyze_system -request_line '' -quit
analyze_system -request_line '' -quit
analyze_system -request_line '' -quit


OpenVOS Release 17.1.0ax, analyze_system Release 17.1.0ax
Current process is 1028, ptep 8D3C3000, Noah_Davids.CAC
OpenVOS Release 17.1.0ax, analyze_system Release 17.1.0ax
Current process is 1029, ptep 8D3C3000, Noah_Davids.CAC
OpenVOS Release 17.1.0ax, analyze_system Release 17.1.0ax
Current process is 1030, ptep 8D3C3000, Noah_Davids.CAC
ready  12:52:21

Figure 12 – Each command in the macro is forked as a separate process

 

Using command macros with VOS style variables will generate syntax errors since the shell doesn’t know what they are. The foo3.cm command macro displays itself and then counts to 9. The display command is executed and the “&set” generates a syntax error.

ssh nd@192.168.77.128 '/bin/sh foo3.cm'                                       

%phx_vos#m16_mas>SysAdmin>Noah_Davids>foo3.cm  13-04-22 07:33:18 mst

display foo3.cm
&set COUNT 1
&label again
display_line &COUNT&
&set COUNT (calc &COUNT& + 1)
&if &COUNT& < 10 &then &goto again

foo3.cm: line 2: syntax error near unexpected token `&s'
foo3.cm: line 2: `&set COUNT 1'
ready  07:33:18

Figure 13 – Command macros with VOS style variables will not work

 

But using shell variables will work. That of course may require extensive rewrites of existing macros. Here is an example of the same macro as a shell script.

ssh nd@192.168.77.128 '/bin/sh foo3u'                                         
cat foo3u
count=1
while [[ $count -le 9 ]]
do
    echo "$count"
    (( count++ ))
done
1
2
3
4
5
6
7
8
9
ready  07:44:41

Figure 14 – Shell script with shell stype variables does work

 

However, you can run your VOS style command macro as a started process and then display the outfile that is produced. The macro start_foo3.cm runs start_process, waits for the process to terminate and then displays the output file without a header. I have modified the foo3.cm to turn off the command and macro lines and also the ready prompt to more fully mimic the output from a command macro run interactively.

start_process foo3.cm -wait                                                   
display foo3.out -no_header

Figure 15 – Command macro to run foo3.cm as a started process

 

With the exception of the login header and the command macro name on the first 2 lines and the “Process finished” line at the end the results are the same as if you ran the macro from the VOS command line.

ssh nd@192.168.77.128 '/bin/sh start_foo3.cm'                                 
Noah_Davids.CAC logged in on %phx_vos#m16 at 13-04-22 10:45:23 mst.
foo3.cm

%phx_vos#m16_mas>SysAdmin>Noah_Davids>foo3.cm  13-04-22 10:45:23 mst

&echo no_input_lines no_command_lines no_macro_lines
set_ready -format off
display foo3.cm
&set COUNT 1
&label again
display_line &COUNT&
&set COUNT (calc &COUNT& + 1)
&if &COUNT& < 10 &then &goto again

1
2
3
4        
5
6
7
8
9
Process finished.
ready  10:45:25

Figure 16 – Results of running foo.cm in a started process

 

So, as you can see while you cannot use telnet that are other ways to automagically login and execute commands.

Pageof 13

Share