7014266: idmapd errors about “localdomain”, or chown failing on nfs4 mount, with “invalid argument”

This document (7014266) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 11 Service Pack 2
SUSE Linux Enterprise Server 11 Service Pack 3

Situation

An NFS client with NFS4 (NFSv4) is having trouble with user identities, and logs errors such as:
rpc.idmapd[18466]: nss_getpwnam: name ‘root@domain.com’ does not map into domain ‘localdomain’
Or when trying to do a “chown”, is may show:
chown: changing ownership of `filename’: Invalid argument

Resolution

The cause of this is somewhat complex, and there are two ways correct this. The simplest way will be listed here, but it may not be possible on some older kernel, or an ideal solution for all environments. So it is recommended to review the “cause” section of this document first, for the other information.
Set the following parameter for the kernel nfs module:
nfs.nfs4_disable_idmapping=1
To take effect at boot, that can be set on the kernel command line. This can be done in Yast –> System –> Boot loader.
Alternatively, it can be set to take effect during slightly later during boot by executing the following command (after which, subsequent reboots should accomplish the setting):
echo “options nfs nfs4_disable_idmapping=1” > /etc/modprobe.d/99-nfs.conf
It can also be set on-the-fly with:
echo 1 > /sys/module/nfs/parameters/nfs4_disable_idmapping
(However, it will only impact mounts performed after it is set. It will be necessary to umount and remount existing nfs4 mounts.)

Cause

NFSv4 handles user identities differently than NFSv3. In v3, an nfs client would simply pass a UID number in chown (and other requests) and the nfs server would accept that (even if the nfs server did not know of an account with that UID number). However, v4 was designed to pass identities in the form of <username>@<id-map-domainname>. To function correctly, that normally requires idmapd (id mapping daemon) to be active at client and server, and for each to consider themselves part of the same id mapping domain.
Chown failures or idmapd errors like the ones documented above are typically a result of either:
1. The username is known to the client but not known to the server, or
2. The idmapd domain name is set differently on the client than it is on the server.
Therefore, this issue can be fixed by insuring that the nfs server and client are configured with the same idmapd domain name (/etc/idmapd.conf) and both have knowledge of the usernames / accounts in question.
However, it is often not convenient to insure that both sides have the same user account knowledge, especially if the nfs server is a filer. The NFS community has recognized that this idmapd feature of NFSv4 is often more troublesome that it is worth, so there are steps and modifications coming into effect to allow the NFSv3 behavior to work even under NFSv4.
SUSE NFS **clients** on SLES 11 SP2 or higher have this ability, but it is not necessarily always the default behavior. Setting the kernel module parameter as described in the “Resolution” section of this document is needed. In mainstream Linux, the default behavior changes in kernel 3.3, i.e. to already have nfs4_disable_idmapping set to 1. So eventually (as newer kernels come into SUSE products) setting this manually will not be needed.
NOTE: Some NFSv4 **servers** may not be prepared to accept this behavior, either. Both sides need to understand this change. If using a Linux NFSv4 server, it may be necessary to use a distribution with kernel 3.4 or higher (for example, openSUSE 12.2 or higher, or upcoming SLES 12). For 3rd party filers, check the nfs configuration for settings related to idmap, uids, etc.

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.

Related:

7018123: Steps to Create a Salt SUSE Manager Client

This document (7018123) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Manager 3 (salt client)

Situation

The SUSE Manager 3 has just been installed. What preparations/steps are needed in order to connect a salt client to SUSE Manager?

Resolution

1. Generate desired activation key.

a. Enter the webUI tool for SUSE Manager.

b. Select the Systems tab at the top of the page.
c. Select the Activation keys tab on the left-hand side of the page.
d. Click the Create Key link in the upper right-hand corner.
i. Description – Enter a description to identify the generated activation key.
ii. Key – Choose either automatic generation by leaving this field blank or enter the key name that is wanted for generation.
iii. Usage – Determine the maximum amount of systems that may be simultaneously registered to the SUSE Manager with this key, or leave blank for unlimited use.
iv. Base Channels – Specify the channels accessible to the client using this key. If a system using this key is not compatible with the selected channel, it will fall back to the default channel. The default channel will automatically assign channels to the client based on installed products.
v. Add-On System Types – Select any additional entitlements for the clients to receive with this key.
vi. Contact Method – Select how clients communicate with the SUSE Manager. (Not applicable to salt clients)
vii. Universal Default – Select whether or not this key should be the primary activation key for this organization.
e. Click Create Activation Key to create the key.
2. Select product(s) to make into channels.
a. Select the Admin tab at the top of the page.
b. Select the SUSE Products sub-tab.
c. Check the boxes of the products you want to be mirrored by the SUSE Manager.
d. Click the Add Products button at the bottom of the page after selecting the desired products to mirror.
e. Wait for mirroring to complete.
3. Create bootstrap repository.
a. Run the following command on the SUSE Manager:
# mgr-create-bootstrap-repo
b. Enter the desired product label.
c. Repeat for all products you need your clients to use.
4. Add the SUSE Manager Tools repository to the client.
a. Run the following command on the client. (The path in the repo will vary slightly based on version and service pack. e.g. below is specific to SLE 11 SP4)
# zypper ar http://<fqdn of SUSE Manager>/pub/repositories/11/4/bootstrap/ spacewalk-tools-repo
5. Refresh the client’s repositories.
a. Run this command on the client:
# zypper ref -s
6. Install all available salt packages on the client.
a. Run this command on the client:
# zypper in salt*
7. Point the client to the SUSE Manager as salt master.
a. Open the /etc/salt/minion file on the client
b. Uncomment (remove # symbol at the beginning of the line) and adjust the following line:
master: <fqdn of suse manager>

8. Create salt grains file telling client which activation key to use.
a. Create /etc/salt/grains file
b. Open /etc/salt/grains file
c. Add the following: (spacing and indentation is important)
susemanager:
activation_key: 1-<key>
9. Restart and enable the salt-minion service.
a. Run matching client version’s commands:
SLE11:
# service salt-minion restart
# chkconfig salt-minion on
SLE12:
# systemctl restart salt-minion.service

# systemctl enable salt-minion.service
10. Onboard the Salt Client from the SUSE Manager
a. Enter the webUI tool for SUSE Manager again.
b. Select the Salt tab at the top of the page
c. Your new machine should be listed as pending. Click accept on the machine you want to accept.
11. Deploy the SUSE Manager certificate to the client
a. Run this command on the SUSE Manager:
For a SLE11 client:
# salt ‘<client minion name>’ state.apply certs.SLES11
For a SLE12 client:
# salt ‘<client minion name>’ state.apply certs
b. At the end of the output from the command above you should see something like this:
Succeeded: 2 (changed=2)
Failed:0
———–
Total states run:2

Additional Information

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.

Related:

7019030: Remote access issue with xdmcp and Gnome.

This document (7019030) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 12 Service Pack 2 (SLES 12 SP2)

SUSE Linux Enterprise Server 12 Service Pack 1 (SLES 12 SP1)

SUSE Linux Enterprise Server 11 Service Pack 4 (SLES 11 SP4)

SUSE Linux Enterprise Server 11 Service Pack 3 (SLES 11 SP3)

Situation

After trying to connect to a SLES server running Gnome desktop via xdmcp protocol, this may not work with some clients, and not with others.

Works with: Xephyr, VcXsrv ( working Windows X server implementation with OpenGL acceleration )

Does not work with: Xming

Resolution

Switch to client that works.

-or-

Use Display Manager and Window Manager that do not require 3D acceleration

For example xdm and icewm.

It is possible to do this by :

  • editing /etc/sysconfig/displaymanager to show :

DISPLAYMANAGER=”xdm”

  • editing /etc/sysconfig/windowmanager to show :

DEFAULT_WM=”icewm”

  • and switching to runlevel 3 and back to 5 or by rebooting teh system.

After that just make sure to configure xdm to enable xdmcp

Cause

Certain xmdcp clients do not support the necessary extensions for acceleration.

As such, gdm and gnome-shell do not work with it.

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.

Related:

7022004: rbd: sysfs write failed, lrbd.service: Unit entered failed state.

This document (7022004) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Enterprise Storage 4

Situation

Running “systemctl start lrbd.service” fails with:

lrbd[81379]: ERROR: command failed

lrbd[81379]: rbd -p PoolName –name client.admin map VolumeName

lrbd[81379]: In some cases useful info is found in syslog – try “dmesg | tail” or so.

lrbd[81379]: rbd: sysfs write failed

lrbd[81379]: rbd: map failed: (110) Connection timed out

systemd[1]: lrbd.service: Main process exited, code=exited, status=1/FAILURE

systemd[1]: Failed to start configures target.service from Ceph.

systemd[1]: lrbd.service: Unit entered failed state.

Resolution

Use “ceph osd reweight-by-utilization” to have ceph reweight osd’s by utilization,

or

Use “ceph osd reweight osd.ID Weight_Value” where osd.ID is the osd number that “ceph osd df” displays and the Weight_Value would be a value less than 1.00.

After issuing the command(s) allow ceph time to re-balance the cluster. Monitor the status with “ceph status” and “ceph osd df”. When ceph no longer claims the osd as being 95% or greater usage, start the lrbd service:

systemctl start lrbd.service

systemctl status lrbd.service

In some cases it will be necessary to add disks (osd’s) to the cluster, so that the cluster has room to grow.

Cause

Ceph was reporting a full osd.

Additional Information

Use “ceph osd df” to show disk usage, note the %USE column from this output will provide the usage percentage.

Also note that:

The mon osd full ratio defaults to 0.95, or 95% of capacity before it stops clients from writing data.
The mon osd nearfull ratio defaults to 0.85, or 85% of capacity when it generates a health warning.

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.

Related:

error while loading shared libraries: libpng14.so.14 when nco_xigen is started on SUSE Linux Enterprise Server (SLES) 11

Environment:

OMNIbus 7.4

SUSE 11 64-bit SP1

The issue has been seen on OMNIbus 7.4 on SUSE 11 64-bit SP1. When starting $NCHOME/omnibus/bin/nco_xigen, the following error occur:

/opt/IBM/tivoli/netcool/omnibus/platform/linux2x86/bin64/nco_xigen: error
while loading shared libraries: libpng14.so.14: cannot open shared object
file: No such file or directory

The other components are running well.

Related:

7021574: X2P Target Discovery Failed: “Linux job did not complete successfully”

This document (7021574) is provided subject to the disclaimer at the end of this document.

Environment

PlateSpin Migrate 12.X

Situation

– The target server registration fails with: “Message: Linux job did not complete successfully”
– From the stack trace, you will be able to see the exception shown below:
“Exception caught in Controller.Execution.Action.run() System.Exception: Linux job did not complete successfully at PlateSpin.Athens.Operations.Machine.DiscoverTarget.DiscoverUnderLinuxControlMachineDetailsAction.GetMachineInfoFromLinuxUnderControlJob(IActionContext context, String controllerId, String machineId) at PlateSpin.Athens.Operations.Machine.DiscoverTarget.DiscoverUnderLinuxControlMachineDetailsAction.Execute(IActionContext context) at PlateSpin.OperationsFramework.Controller.Execution.Action.run(Boolean rollback) Action status: Failed”

Resolution

To workaround the issue, kindly refer to the troubleshooting steps below.
– On the target machine under PlateSpin Take Control, run command: fdisk -l. If it does not provide any information, this can mean that there might be no storage assigned to the physical target or the disks are not recognized by the PlateSpin Take Control ISO.
– Download the correct storage controller driver for SLES 11 SP3(the version which PlateSpin Take Control ISO is based)
– Inject the driver to the PlateSpin Take Control ISO as per this KB article: 7005990
– Reattempt discovery by booting the target with the updated PlateSpin Take Control ISO

Cause

This issue generally happens when the disks attached on the target machine are not recognized by the PlateSpin Take Control ISO.

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.

Related: