ScreenJet Sponsor Message

December 2003

net.digest summarizes helpful technical discussions on the comp.sys.hp.mpe Internet newsgroup and 3000-L mailing list. Advice here is offered on a best-effort, Good Samaritan basis. Test these concepts for yourself before applying them to your HP 3000s.

Edited by John Burke

3000-L is a truly unique experience. Recently I have had the opportunity (somewhat forced, but that is the long story we have all been living since November 14, 2001) to compare 3000-L with MIDRANGE-L. MIDRANGE-L is the listserver where those interested in the technical aspects of the iSeries (AS/400) hang out. It is very collegial, just like 3000-L, and a lot of good advice is dispensed. For example, I was able to solve a problem I was having with an iSeries, a problem not documented on IBM’s public web sites, by searching the MIDRANGE-L archives.

However, the denizens of MIDRANGE-L just do not seem to have quite the same passion, not only for their system of choice, but for life in general, as those of 3000-L. Of course sometimes that passion for life can be a bit overwhelming as threads whose roots are either in politics or in religion occasionally hijack the list. A casual observer might think nothing of technical merit was discussed this month, but he would be wrong.

I always like to hear from readers of net.digest and Hidden Value. Even negative comments are welcome. If you spot something on 3000-L and would like someone to elaborate on what was discussed, let me know. You can reach me at john@burke-consulting.com.

More Peripherals 101 for the Homesteader and Fence-Sitter

The question was “How long will HP support the A400?” The answer of course is December 31, 2006. One person suggested buying up multiples of all peripheral equipment and putting them in storage to use as replacements as a way to be good until 2020. This allowed peripheral expert Denys Beauchemin to chime in with the following. “For an A or N-class, the issue of peripheral hardware is nowhere near as dire as for the NIO systems. The problem with 9x9, 99x and 9x8 systems has to do with HVD (high voltage differential or FWSCSI in MPE parlance) SCSI devices such as disk drives and tape drives. There has not been an HVD disk drive manufactured in a few years and they probably never will be again. The LVD devices used in A and N systems are still being manufactured and should be for a while longer. However, please understand this situation will change in the future as cheap, fast and huge capacity serial ATA or SATA drives take over the world and the PCI architecture evolves into the PCI-Express architecture starting in 2004.

“The server of 2006 will be vastly different than the server in 2003. If you have a PCI system (A and N) there should be a good supply of newly or recently manufactured LVD disk and tape drives for several years to come. I would say however, that much beyond 2010 should be problematic, all things being equal. If you have a pre-PCI system (9xx), you have a challenge and some alternatives. Technology does exist to allow you to connect the latest fiber or LVD disk drive or arrays to your FWSCSI connections. These solutions work and work very well but HP does not support them. For your SE SCSI connections, Seagate is producing new technology disk drives with an SE SCSI connection, especially targeted at legacy systems.”

Note that HP engineers maintain that HP firmware (the stuff that makes off-the-shelf disk drives “HP” drives) is important, especially in high-end systems with the newer very fast drives, to avoid IO problems. I’ve written about this several times under the heading SCSI is SCSI.

Words to the wise about Samba

Samba can often play a key role in transition plans, so I thought the following question and the answers provided by two MPE/iX experts deserved repeating. The question was, “Is anyone aware of performance issues or security issues with Samba on an HP 3000? We currently have a N4000 that is behind a firewall. Our application provider is telling us that we need Samba to serve up .jpg files, but that it was ill-advised as Samba causes performance issues on the HP3000 and that it has security issues. Any insight is appreciated.”

Mark Bixby, who ported Apache among other things, replied, “For best Samba performance you want to run the JSMB job instead of running Samba under INETD. As a separate job, you can run SMBD in whatever dispatching queue (CS, DS, ES, and so on) is appropriate for your machine. Make sure your Samba content is stored as MPE bytestream files. You will pay a performance penalty if you are using MPE record-oriented file types. Samba on MPE is no more or no less secure than Samba on any other platform. Follow good Samba security practices by disabling guest access (all versions of Samba on MPE) and enabling encrypted passwords (Samba 2.2.8a on MPE). For more information about Samba 2.2.8a on MPE, please see jazz.external.hp.com /src/samba.”

Lars Appel, who did the original Samba port, added, “Maybe the application provider could provide some details to his advice. Maybe he is referring to the fact that older Samba/iX versions do not handle the ‘encrypt passwords’ feature and rely on plain text passwords, similar to what telnet, NS/VT, or FTP connections do. Another issue, but not 3000 specific, is whether you configure shares that allow guest access (no passwords) and are browseable (i.e., can be seen in network neighborhood or with net view \\hostname) and allow write access, like the [public] example in the sample smb.conf file.

“The ‘popular’ Windows based worms can use such shares for their evil purpose of propagating themselves throughout the network. Infected files on a 3000 share don’t cause trouble for the 3000 itself; they only are dangerous for innocent PC users double-clicking them. So you’d want to avoid shares with guest ok, browseable and write ok.”

I used Samba myself for over three years in a production environment during a migration to move data back and forth between MPE applications and SAP’s R/3 running on Windows. MPE programs would extract data to bytestream files that were then read directly off the HP 3000 by ABAP programs running under SAP. Other ABAP programs would write directly to bytestream files on the HP 3000 that other MPE programs would read and process. Worked so well, we sometimes forgot we were even doing it.

More on Samba

Many people have difficulty the first time they try to use Samba. It is one of those systems that are so loaded with options it can become very confusing. The question went like this, “I am having trouble with Samba (207). I have set up a share in smb.conf:

[prod]

comment = share for PROD
path = /PROD/PUB
username = mgr.prod
writeable = Yes
guest ok = Yes

“When I open up the directory I can see the file that is already in PUB.PROD, but when I try to drag a file there using Windows Explorer, I get the message (from Windows 2000): Cannot copy VOLGMT64: Access is denied. The source file may be in use.

“I have the feeling that it is an erroneous message (the file isn’t in use) and if I leave the path at /tmp, I can drop it just fine. The engineer at the Response Center thought that I may not be able to drop it into the MPE filespace and that it had to go into a Posix directory. That seemed kind of strange to me. So, is there another setting I need to allow me to drop into PUB.PROD? By the way, I have SWAT running, which is much easier than editing smb.conf with vi.”

John Clogg, who obviously has struggled with this himself, replied, “I have been dealing with exactly the same thing. Since you have guest access enabled, I assume you are not entering the password for MGR.PROD to gain access to it. Therefore, the SMB process is acting as if you are the guest user (probably MGR.SAMBA). Since you can’t build files across account boundaries (unless you have SM capability), it honors the MPE access restriction and won’t let you build a file there. If you had an HFS directory in that account, you could do a chmod on the directory to allow update access to the directory, which would allow you to save files there. The possible solutions are (1) change the guest user in smb.conf to mgr.prod, (2) give mgr.samba SM capability (possible security issues there), (3) create an HFS directory to store the file in and allow write access to the directory, or (4) do not use guest access. If anyone knows another approach, I would love to hear it. This has caused me some major headaches!”

Lars Appel then gave a short tutorial that should be part of every system manager’s System Manual. “John Clogg already hit the nail on the head with his reply. Your share is ‘guest ok’ and will thus use the ‘guest account’ from the [global] section to access the files. The ‘username’ is irrelevant here, it would be used to check the password against, if you had ‘guest ok = no’. In that case I would also add ‘only user = yes’, because SMBD would otherwise use several other attempts to guess the user (e.g., share name, windows logon, netbios name of client, potentially mapped via user.map) to try the password against. This can be confusing, thus I prefer to override with ‘username=x.y’ and ‘only user = yes’.

“For file access problems after successful ‘map network drive’, it is typically useful to examine the output of smbstatus (the showjob of samba and check on which (MPE) user’s behalf the access to the files is performed for the share at hand. You can then logon as that very user and try the same file access from CI or Shell to get an idea why SMBD might fail to do what you want. The CI or Shell has typically much better error messages (and means to examine the permissions) then the Windows PC presents. Two share definition examples that I typically use (besides [homes]):

[alpha]

comment = guest ok / public means: no password needed
path = /ACCOUNT/GROUP
guest ok = yes
write ok = no
; guest account = user.account
; browseable = no

[bravo]

comment = this share requires MPE password validation
path = /ACCOUNT/GROUP
guest ok = no
write ok = yes
user = user.account
only user = yes

“For [alpha] you typically don’t want ‘write ok’ and ‘browseable’ at the same time, because popular worms can then find and use the shared directory to try replicating themselves. No harm for MPE, but possible harm for the potentially infected/corrupted files and other users visiting the same share. I believe, you can override ‘guest account’ at the share level; thus my commented line in the [alpha] example. Depending on the MPE file system level permissions in /ACCOUNT/GROUP, you might need this for successful file access/modification/creation from the client side.”