Software Distributor (SD-UX) Administration Guide HP-UX 11i v1, 11i v2, and 11i v3 (762797-001, March 2014)

Table Of Contents
Xlib: connection to <display> refused by server
Xlib: Client is not authorized to connect to Server
Error: Cant Open display.
Check that you have set the $DISPLAY environment variable correctly on the remote system to
identify your display. If it is correct, you may have to enable the remote host to make connections
to your X server via the xhost(1) command or by modifying your /etc/X*.hosts file.
If you see the error message:
swinstall: Error: cannot read file:
/usr/lib/sw/ui/smc_install_copy.ui
or
swremove: Error: cannot read file:
/usr/lib/sw/ui/smc_remove.ui
the system is telling you that the file /usr/lib/sw/ui/smc_install_copy.ui must be installed
on the system to run either swinstall or swcopy interactively or that the
/usr/lib/sw/ui/smc_remove.ui file must be installed to run swremove. Make sure that the
directory /usr/lib/sw/ui exists and includes the requested file. If the file does not exist, you
must reinstall the SD-CMDS fileset from your OS media.
Access To An Object Is Denied
Denial of access to SD-UX objects may have a number of causes, including:
ACL permissions
Inter-host secrets
Working with image copies of depots
Resolution
Generally, when SD-UX denies access to an object, a message tells you that you do not have the
required access permission. Yet, it may be unclear which object is not accessible. For example,
when you use swcopy to copy a product from system A to a depot, SD-UX checks these ACLs:
1. If the destination depot does NOT exist, the host ACL is checked to verify that the user has
“insert” permission.
2. If the destination depot does exist, the depot ACL is checked to verify that the user has write
permission.
3. The source depot’s ACL is checked to make sure the user has read permission on the source
depot.
4. The source product’s ACL is also checked to make sure that the user and the destination system
both have read access to the product.
If any of these access permissions is absent, the whole operation is disallowed, and you must read
the error message carefully to understanding the exact cause. To see more about what type of
security or access problems exist, see the daemon log file on the target system: /var/adm/sw/
swagentd.log
The Effects of ACL Modifications
The default ACLs make it fairly easy to administer ACLs, but do not always give the desired level
of access control. When you change an ACL to restrict access, especially by removing the
any_other read permission, you may restrict access in unexpected ways. Host entries are required
for any destination systems for swcopy and swinstall operations.
See Chapter 9: “SD-UX Security ” (page 141) for a full discussion of the access tests performed or
each operation.
Do Not Modify ACL Files Without swacl
Since SD-UX stores ACLs in the file system as plain text files, you may try to edit them with a
conventional editor. This can lead to unexpected corruption of the ACL. Most cases of this corruption
simply result in a message indicating the corruption, but inserting additions to the ACL file without
256 Troubleshooting