Need UDEV to set device ownership with AD/LDAP users and groups after sssd starts

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP

up vote
1
down vote

favorite

The given constraints are:

  1. System: Oracle 12.2. ASM cluster
  2. Must use AD/LDAP based users and groups for software and ASM disk device ownership

The oracle ASM cluster uses a number of raw block devices, which must be owned by the Oracle software owner (grid) and admin group (asmadmin). This is usually accomplished by creating udev rules like this one:

ENV{DM_UUID}=="<dm_uuid>", SYMLINK+="oracleasm/asmsysdga", OWNER="grid", GROUP="asmadmin", MODE="0660"

This works well when the user and group are local. When they are AD users, testing the rule with udevadm test also works well, but on reboot udev is triggered well before the AD/LDAP integration is available and resolving the username understandably fails. As a result, the ASM devices end up owned by root:root instead.

UDEV does not attempt to resolve the username after the rules are loaded, so we need a reliable way to make udev reload the rules and reapply the rule set to the ASM devices after sssd.service has started and AD/LDAP integration is available, and before the oracle-ohasd.service starts.

It has been suggested to simply edit the oracle supplied script to include:

udevadm control --reload
udevadm trigger ...

before the cluster proper starts. However, that seems to be less appropriate as the script is vendor provided and could be replaced by them anytime (via a patch). And it is a kludge that is easily forgotten.

Is there a better and more supported way in systemd to reload the udev rules during boot-up at the point where AD integration works, and before oracle-ohasd starts?

share|improve this question

  • 1

    You should at least consider adding the users locally. If you google for this issue, you’ll see that advice often, for instance here in the Arch Linux wiki. There’s really no problem with the user being defined in both places. As long as their definition is stable enough (but then, if those users are changing, you have other problems.) And as long as it’s just a handful of users and groups. Particularly if it’s only user grid and group asmadmin like in your case… Anyways, at least take that into consideration.
    – Filipe Brandenburger
    Nov 29 at 2:54

  • 1

    I could not agree more. In fact Oracle explicitly advises not to use AD based users for this purpose. Sadly though, I have no say in the matter – we have to live with it and work around.
    – Tony
    Nov 29 at 5:45

  • If you know it’s a work around, having an additional kludge with an extra script doesn’t sound like a “dirty” solution. I don’t know your exact setup, but I suppose it should be possible to find a systemd node for the AD/LDAP service, and insert your own service with a condition to run after AD/LDAP and before oracle-ohasd.service. That service would just run the udevadm reload. As it’s an additional systemd configuration file, it won’t get overwritten by upgrades.
    – dirkt
    Nov 29 at 8:02

up vote
1
down vote

favorite

The given constraints are:

  1. System: Oracle 12.2. ASM cluster
  2. Must use AD/LDAP based users and groups for software and ASM disk device ownership

The oracle ASM cluster uses a number of raw block devices, which must be owned by the Oracle software owner (grid) and admin group (asmadmin). This is usually accomplished by creating udev rules like this one:

ENV{DM_UUID}=="<dm_uuid>", SYMLINK+="oracleasm/asmsysdga", OWNER="grid", GROUP="asmadmin", MODE="0660"

This works well when the user and group are local. When they are AD users, testing the rule with udevadm test also works well, but on reboot udev is triggered well before the AD/LDAP integration is available and resolving the username understandably fails. As a result, the ASM devices end up owned by root:root instead.

UDEV does not attempt to resolve the username after the rules are loaded, so we need a reliable way to make udev reload the rules and reapply the rule set to the ASM devices after sssd.service has started and AD/LDAP integration is available, and before the oracle-ohasd.service starts.

It has been suggested to simply edit the oracle supplied script to include:

udevadm control --reload
udevadm trigger ...

before the cluster proper starts. However, that seems to be less appropriate as the script is vendor provided and could be replaced by them anytime (via a patch). And it is a kludge that is easily forgotten.

Is there a better and more supported way in systemd to reload the udev rules during boot-up at the point where AD integration works, and before oracle-ohasd starts?

share|improve this question

  • 1

    You should at least consider adding the users locally. If you google for this issue, you’ll see that advice often, for instance here in the Arch Linux wiki. There’s really no problem with the user being defined in both places. As long as their definition is stable enough (but then, if those users are changing, you have other problems.) And as long as it’s just a handful of users and groups. Particularly if it’s only user grid and group asmadmin like in your case… Anyways, at least take that into consideration.
    – Filipe Brandenburger
    Nov 29 at 2:54

  • 1

    I could not agree more. In fact Oracle explicitly advises not to use AD based users for this purpose. Sadly though, I have no say in the matter – we have to live with it and work around.
    – Tony
    Nov 29 at 5:45

  • If you know it’s a work around, having an additional kludge with an extra script doesn’t sound like a “dirty” solution. I don’t know your exact setup, but I suppose it should be possible to find a systemd node for the AD/LDAP service, and insert your own service with a condition to run after AD/LDAP and before oracle-ohasd.service. That service would just run the udevadm reload. As it’s an additional systemd configuration file, it won’t get overwritten by upgrades.
    – dirkt
    Nov 29 at 8:02

up vote
1
down vote

favorite

up vote
1
down vote

favorite

The given constraints are:

  1. System: Oracle 12.2. ASM cluster
  2. Must use AD/LDAP based users and groups for software and ASM disk device ownership

The oracle ASM cluster uses a number of raw block devices, which must be owned by the Oracle software owner (grid) and admin group (asmadmin). This is usually accomplished by creating udev rules like this one:

ENV{DM_UUID}=="<dm_uuid>", SYMLINK+="oracleasm/asmsysdga", OWNER="grid", GROUP="asmadmin", MODE="0660"

This works well when the user and group are local. When they are AD users, testing the rule with udevadm test also works well, but on reboot udev is triggered well before the AD/LDAP integration is available and resolving the username understandably fails. As a result, the ASM devices end up owned by root:root instead.

UDEV does not attempt to resolve the username after the rules are loaded, so we need a reliable way to make udev reload the rules and reapply the rule set to the ASM devices after sssd.service has started and AD/LDAP integration is available, and before the oracle-ohasd.service starts.

It has been suggested to simply edit the oracle supplied script to include:

udevadm control --reload
udevadm trigger ...

before the cluster proper starts. However, that seems to be less appropriate as the script is vendor provided and could be replaced by them anytime (via a patch). And it is a kludge that is easily forgotten.

Is there a better and more supported way in systemd to reload the udev rules during boot-up at the point where AD integration works, and before oracle-ohasd starts?

share|improve this question

The given constraints are:

  1. System: Oracle 12.2. ASM cluster
  2. Must use AD/LDAP based users and groups for software and ASM disk device ownership

The oracle ASM cluster uses a number of raw block devices, which must be owned by the Oracle software owner (grid) and admin group (asmadmin). This is usually accomplished by creating udev rules like this one:

ENV{DM_UUID}=="<dm_uuid>", SYMLINK+="oracleasm/asmsysdga", OWNER="grid", GROUP="asmadmin", MODE="0660"

This works well when the user and group are local. When they are AD users, testing the rule with udevadm test also works well, but on reboot udev is triggered well before the AD/LDAP integration is available and resolving the username understandably fails. As a result, the ASM devices end up owned by root:root instead.

UDEV does not attempt to resolve the username after the rules are loaded, so we need a reliable way to make udev reload the rules and reapply the rule set to the ASM devices after sssd.service has started and AD/LDAP integration is available, and before the oracle-ohasd.service starts.

It has been suggested to simply edit the oracle supplied script to include:

udevadm control --reload
udevadm trigger ...

before the cluster proper starts. However, that seems to be less appropriate as the script is vendor provided and could be replaced by them anytime (via a patch). And it is a kludge that is easily forgotten.

Is there a better and more supported way in systemd to reload the udev rules during boot-up at the point where AD integration works, and before oracle-ohasd starts?

systemd udev

share|improve this question

share|improve this question

share|improve this question

share|improve this question

asked Nov 29 at 1:31

Tony

305

305

  • 1

    You should at least consider adding the users locally. If you google for this issue, you’ll see that advice often, for instance here in the Arch Linux wiki. There’s really no problem with the user being defined in both places. As long as their definition is stable enough (but then, if those users are changing, you have other problems.) And as long as it’s just a handful of users and groups. Particularly if it’s only user grid and group asmadmin like in your case… Anyways, at least take that into consideration.
    – Filipe Brandenburger
    Nov 29 at 2:54

  • 1

    I could not agree more. In fact Oracle explicitly advises not to use AD based users for this purpose. Sadly though, I have no say in the matter – we have to live with it and work around.
    – Tony
    Nov 29 at 5:45

  • If you know it’s a work around, having an additional kludge with an extra script doesn’t sound like a “dirty” solution. I don’t know your exact setup, but I suppose it should be possible to find a systemd node for the AD/LDAP service, and insert your own service with a condition to run after AD/LDAP and before oracle-ohasd.service. That service would just run the udevadm reload. As it’s an additional systemd configuration file, it won’t get overwritten by upgrades.
    – dirkt
    Nov 29 at 8:02

  • 1

    You should at least consider adding the users locally. If you google for this issue, you’ll see that advice often, for instance here in the Arch Linux wiki. There’s really no problem with the user being defined in both places. As long as their definition is stable enough (but then, if those users are changing, you have other problems.) And as long as it’s just a handful of users and groups. Particularly if it’s only user grid and group asmadmin like in your case… Anyways, at least take that into consideration.
    – Filipe Brandenburger
    Nov 29 at 2:54

  • 1

    I could not agree more. In fact Oracle explicitly advises not to use AD based users for this purpose. Sadly though, I have no say in the matter – we have to live with it and work around.
    – Tony
    Nov 29 at 5:45

  • If you know it’s a work around, having an additional kludge with an extra script doesn’t sound like a “dirty” solution. I don’t know your exact setup, but I suppose it should be possible to find a systemd node for the AD/LDAP service, and insert your own service with a condition to run after AD/LDAP and before oracle-ohasd.service. That service would just run the udevadm reload. As it’s an additional systemd configuration file, it won’t get overwritten by upgrades.
    – dirkt
    Nov 29 at 8:02

1

1

You should at least consider adding the users locally. If you google for this issue, you’ll see that advice often, for instance here in the Arch Linux wiki. There’s really no problem with the user being defined in both places. As long as their definition is stable enough (but then, if those users are changing, you have other problems.) And as long as it’s just a handful of users and groups. Particularly if it’s only user grid and group asmadmin like in your case… Anyways, at least take that into consideration.
– Filipe Brandenburger
Nov 29 at 2:54

You should at least consider adding the users locally. If you google for this issue, you’ll see that advice often, for instance here in the Arch Linux wiki. There’s really no problem with the user being defined in both places. As long as their definition is stable enough (but then, if those users are changing, you have other problems.) And as long as it’s just a handful of users and groups. Particularly if it’s only user grid and group asmadmin like in your case… Anyways, at least take that into consideration.
– Filipe Brandenburger
Nov 29 at 2:54

1

1

I could not agree more. In fact Oracle explicitly advises not to use AD based users for this purpose. Sadly though, I have no say in the matter – we have to live with it and work around.
– Tony
Nov 29 at 5:45

I could not agree more. In fact Oracle explicitly advises not to use AD based users for this purpose. Sadly though, I have no say in the matter – we have to live with it and work around.
– Tony
Nov 29 at 5:45

If you know it’s a work around, having an additional kludge with an extra script doesn’t sound like a “dirty” solution. I don’t know your exact setup, but I suppose it should be possible to find a systemd node for the AD/LDAP service, and insert your own service with a condition to run after AD/LDAP and before oracle-ohasd.service. That service would just run the udevadm reload. As it’s an additional systemd configuration file, it won’t get overwritten by upgrades.
– dirkt
Nov 29 at 8:02

If you know it’s a work around, having an additional kludge with an extra script doesn’t sound like a “dirty” solution. I don’t know your exact setup, but I suppose it should be possible to find a systemd node for the AD/LDAP service, and insert your own service with a condition to run after AD/LDAP and before oracle-ohasd.service. That service would just run the udevadm reload. As it’s an additional systemd configuration file, it won’t get overwritten by upgrades.
– dirkt
Nov 29 at 8:02

1 Answer
1

active

oldest

votes

up vote
2
down vote

accepted

Implementing the Kludge

If you really want to go the route of the workaround asking udev to re-evaluate its rules after AD/LDAP is reachable, then I guess my suggestion would be to use a dedicated service unit to run those udevadm commands.

Order that unit appropriately so that it runs after sssd.service is up (since that’s what’s querying your AD/LDAP backend) and also after network-online.target (to ensure it will be reachable, assuming sssd doesn’t have a cache of those users/groups yet) and before the service that needs those devices. (For illustration here, let’s assume it’s called oracle-asm.service.)

To do so, create a new service unit, such as /etc/systemd/system/asm-device-ownership.service with contents such as:

[Unit]
Description=Update ownership of Oracle ASM devices
After=sssd.service network-online.target
Before=oracle-asm.service

[Service]
Type=oneshot
ExecStart=/bin/udevadm control --reload
ExecStart=/bin/udevadm trigger --settle ... (your devices here) ...

[Install]
WantedBy=multi-user.target

Once that unit is in place, make systemd aware of it with command sudo systemctl daemon-reload and enable it with sudo systemctl enable asm-device-ownership.service.

Also notice I’m recommending using udevadm trigger --settle, in order to make that command synchronous. You want to make sure the operation is waited for, since the systemd ordering will ensure this service unit (setting up ownership of those devices) is finished before the one that depends on it (the one using the ASM devices) will start.

This should work, but there are a lot of moving parts at early reboot and reloading udev and retriggering rules in the middle of it might prove to have issues… So if you go this route, make sure you test this setup enough to make sure it’s actually reliable.


Having said that, I really recommend against using this kludge.

Instead, consider one of the alternative solutions below:

Replicating user/group locally

In the comments, I had previously recommended creating the same users locally, as described in this article in the Arch Linux wiki.

There’s not really much of a problem in having the user in both local /etc/passwd and /etc/group and also in AD/LDAP, considering the definitions in AD/LDAP will not change (but then, if they do change, you will probably have trouble anyways, particularly with the systems that are already running.)

I can see one problem with the local copy, which is if you want to manage the members of the asmadmin group on AD/LDAP and that information is likely to actually change (so duplicating it in local /etc/group is a problem.)

It turns out glibc 2.24 has a solution for that, by specifying that entries should be merged in /etc/nsswitch.conf:

passwd: files sssd
group:  files [SUCCESS=merge] sssd

(See the man page for nsswitch.conf for details on [SUCCESS=merge].)

But this option has some drawbacks:

  • The nsswitch.conf option to merge entries is only available starting on glibc 2.24, which is fairly recent. For instance, RHEL 7 ships version 2.17, so that’s not available there.
  • The “merge” feature is not perfect, the man page for instance describes how it doesn’t work with getgrent which is used to list all groups…
  • Using “merge” means sssd will be attempted for resolution even for groups which are present in local files! This potentially means longer delays in early boot, before sssd is actually up… (In fact, most of the solutions involving replicating users/groups locally are trying to solve the problems of the timeouts before the external services are available.)

So perhaps a better solution is:

Encode numeric UID/GID in udev configuration instead!

As mentioned before, I expect your user grid will have a fixed UID which will not change in time (since changing it during system operation would likely create more problems) and same for GID of asmadmin.

If that’s indeed the case, if you can rely on that UID and GID being fixed and dedicated, then consider encoding those in the udev rule, which can take numeric UIDs and GIDs in the OWNER and GROUP fields.

For example, if grid has UID 501 and asmadmin has GID 601, then use the following rule instead:

ENV{DM_UUID}=="<dm_uuid>", SYMLINK+="oracleasm/asmsysdga", OWNER="501", GROUP="601", MODE="0660"

This way, no user/group resolution is needed early in boot when udev is setting up these devices, but then when user/group resolution from AD/LDAP is available, the ownership will be correctly set for ASM to work with those devices.

That’s probably the best solution for this problem, really no significant drawbacks there.

share|improve this answer

  • Thanks, I did not know that that rule also takes UID/GID. I don’t necessarily want to implement a kludge, which is why I posted the question, failing to find any comprehensive documentation on either udevd (and it’s rules) or systemd. Do you by any chance have a link to such documentation?
    – Tony
    Dec 3 at 1:35

Your Answer

StackExchange.ready(function() {
var channelOptions = {
tags: “”.split(” “),
id: “106”
};
initTagRenderer(“”.split(” “), “”.split(” “), channelOptions);

StackExchange.using(“externalEditor”, function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using(“snippets”, function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: ‘answer’,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: “”,
imageUploader: {
brandingHtml: “Powered by u003ca class=”icon-imgur-white” href=”https://imgur.com/”u003eu003c/au003e”,
contentPolicyHtml: “User contributions licensed under u003ca href=”https://creativecommons.org/licenses/by-sa/3.0/”u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href=”https://stackoverflow.com/legal/content-policy”u003e(content policy)u003c/au003e”,
allowUrls: true
},
onDemand: true,
discardSelector: “.discard-answer”
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved
draft discarded

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin(‘.new-post-login’, ‘https%3a%2f%2funix.stackexchange.com%2fquestions%2f484807%2fneed-udev-to-set-device-ownership-with-ad-ldap-users-and-groups-after-sssd-start%23new-answer’, ‘question_page’);
}
);

Post as a guest

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
2
down vote

accepted

Implementing the Kludge

If you really want to go the route of the workaround asking udev to re-evaluate its rules after AD/LDAP is reachable, then I guess my suggestion would be to use a dedicated service unit to run those udevadm commands.

Order that unit appropriately so that it runs after sssd.service is up (since that’s what’s querying your AD/LDAP backend) and also after network-online.target (to ensure it will be reachable, assuming sssd doesn’t have a cache of those users/groups yet) and before the service that needs those devices. (For illustration here, let’s assume it’s called oracle-asm.service.)

To do so, create a new service unit, such as /etc/systemd/system/asm-device-ownership.service with contents such as:

[Unit]
Description=Update ownership of Oracle ASM devices
After=sssd.service network-online.target
Before=oracle-asm.service

[Service]
Type=oneshot
ExecStart=/bin/udevadm control --reload
ExecStart=/bin/udevadm trigger --settle ... (your devices here) ...

[Install]
WantedBy=multi-user.target

Once that unit is in place, make systemd aware of it with command sudo systemctl daemon-reload and enable it with sudo systemctl enable asm-device-ownership.service.

Also notice I’m recommending using udevadm trigger --settle, in order to make that command synchronous. You want to make sure the operation is waited for, since the systemd ordering will ensure this service unit (setting up ownership of those devices) is finished before the one that depends on it (the one using the ASM devices) will start.

This should work, but there are a lot of moving parts at early reboot and reloading udev and retriggering rules in the middle of it might prove to have issues… So if you go this route, make sure you test this setup enough to make sure it’s actually reliable.


Having said that, I really recommend against using this kludge.

Instead, consider one of the alternative solutions below:

Replicating user/group locally

In the comments, I had previously recommended creating the same users locally, as described in this article in the Arch Linux wiki.

There’s not really much of a problem in having the user in both local /etc/passwd and /etc/group and also in AD/LDAP, considering the definitions in AD/LDAP will not change (but then, if they do change, you will probably have trouble anyways, particularly with the systems that are already running.)

I can see one problem with the local copy, which is if you want to manage the members of the asmadmin group on AD/LDAP and that information is likely to actually change (so duplicating it in local /etc/group is a problem.)

It turns out glibc 2.24 has a solution for that, by specifying that entries should be merged in /etc/nsswitch.conf:

passwd: files sssd
group:  files [SUCCESS=merge] sssd

(See the man page for nsswitch.conf for details on [SUCCESS=merge].)

But this option has some drawbacks:

  • The nsswitch.conf option to merge entries is only available starting on glibc 2.24, which is fairly recent. For instance, RHEL 7 ships version 2.17, so that’s not available there.
  • The “merge” feature is not perfect, the man page for instance describes how it doesn’t work with getgrent which is used to list all groups…
  • Using “merge” means sssd will be attempted for resolution even for groups which are present in local files! This potentially means longer delays in early boot, before sssd is actually up… (In fact, most of the solutions involving replicating users/groups locally are trying to solve the problems of the timeouts before the external services are available.)

So perhaps a better solution is:

Encode numeric UID/GID in udev configuration instead!

As mentioned before, I expect your user grid will have a fixed UID which will not change in time (since changing it during system operation would likely create more problems) and same for GID of asmadmin.

If that’s indeed the case, if you can rely on that UID and GID being fixed and dedicated, then consider encoding those in the udev rule, which can take numeric UIDs and GIDs in the OWNER and GROUP fields.

For example, if grid has UID 501 and asmadmin has GID 601, then use the following rule instead:

ENV{DM_UUID}=="<dm_uuid>", SYMLINK+="oracleasm/asmsysdga", OWNER="501", GROUP="601", MODE="0660"

This way, no user/group resolution is needed early in boot when udev is setting up these devices, but then when user/group resolution from AD/LDAP is available, the ownership will be correctly set for ASM to work with those devices.

That’s probably the best solution for this problem, really no significant drawbacks there.

share|improve this answer

  • Thanks, I did not know that that rule also takes UID/GID. I don’t necessarily want to implement a kludge, which is why I posted the question, failing to find any comprehensive documentation on either udevd (and it’s rules) or systemd. Do you by any chance have a link to such documentation?
    – Tony
    Dec 3 at 1:35

up vote
2
down vote

accepted

Implementing the Kludge

If you really want to go the route of the workaround asking udev to re-evaluate its rules after AD/LDAP is reachable, then I guess my suggestion would be to use a dedicated service unit to run those udevadm commands.

Order that unit appropriately so that it runs after sssd.service is up (since that’s what’s querying your AD/LDAP backend) and also after network-online.target (to ensure it will be reachable, assuming sssd doesn’t have a cache of those users/groups yet) and before the service that needs those devices. (For illustration here, let’s assume it’s called oracle-asm.service.)

To do so, create a new service unit, such as /etc/systemd/system/asm-device-ownership.service with contents such as:

[Unit]
Description=Update ownership of Oracle ASM devices
After=sssd.service network-online.target
Before=oracle-asm.service

[Service]
Type=oneshot
ExecStart=/bin/udevadm control --reload
ExecStart=/bin/udevadm trigger --settle ... (your devices here) ...

[Install]
WantedBy=multi-user.target

Once that unit is in place, make systemd aware of it with command sudo systemctl daemon-reload and enable it with sudo systemctl enable asm-device-ownership.service.

Also notice I’m recommending using udevadm trigger --settle, in order to make that command synchronous. You want to make sure the operation is waited for, since the systemd ordering will ensure this service unit (setting up ownership of those devices) is finished before the one that depends on it (the one using the ASM devices) will start.

This should work, but there are a lot of moving parts at early reboot and reloading udev and retriggering rules in the middle of it might prove to have issues… So if you go this route, make sure you test this setup enough to make sure it’s actually reliable.


Having said that, I really recommend against using this kludge.

Instead, consider one of the alternative solutions below:

Replicating user/group locally

In the comments, I had previously recommended creating the same users locally, as described in this article in the Arch Linux wiki.

There’s not really much of a problem in having the user in both local /etc/passwd and /etc/group and also in AD/LDAP, considering the definitions in AD/LDAP will not change (but then, if they do change, you will probably have trouble anyways, particularly with the systems that are already running.)

I can see one problem with the local copy, which is if you want to manage the members of the asmadmin group on AD/LDAP and that information is likely to actually change (so duplicating it in local /etc/group is a problem.)

It turns out glibc 2.24 has a solution for that, by specifying that entries should be merged in /etc/nsswitch.conf:

passwd: files sssd
group:  files [SUCCESS=merge] sssd

(See the man page for nsswitch.conf for details on [SUCCESS=merge].)

But this option has some drawbacks:

  • The nsswitch.conf option to merge entries is only available starting on glibc 2.24, which is fairly recent. For instance, RHEL 7 ships version 2.17, so that’s not available there.
  • The “merge” feature is not perfect, the man page for instance describes how it doesn’t work with getgrent which is used to list all groups…
  • Using “merge” means sssd will be attempted for resolution even for groups which are present in local files! This potentially means longer delays in early boot, before sssd is actually up… (In fact, most of the solutions involving replicating users/groups locally are trying to solve the problems of the timeouts before the external services are available.)

So perhaps a better solution is:

Encode numeric UID/GID in udev configuration instead!

As mentioned before, I expect your user grid will have a fixed UID which will not change in time (since changing it during system operation would likely create more problems) and same for GID of asmadmin.

If that’s indeed the case, if you can rely on that UID and GID being fixed and dedicated, then consider encoding those in the udev rule, which can take numeric UIDs and GIDs in the OWNER and GROUP fields.

For example, if grid has UID 501 and asmadmin has GID 601, then use the following rule instead:

ENV{DM_UUID}=="<dm_uuid>", SYMLINK+="oracleasm/asmsysdga", OWNER="501", GROUP="601", MODE="0660"

This way, no user/group resolution is needed early in boot when udev is setting up these devices, but then when user/group resolution from AD/LDAP is available, the ownership will be correctly set for ASM to work with those devices.

That’s probably the best solution for this problem, really no significant drawbacks there.

share|improve this answer

  • Thanks, I did not know that that rule also takes UID/GID. I don’t necessarily want to implement a kludge, which is why I posted the question, failing to find any comprehensive documentation on either udevd (and it’s rules) or systemd. Do you by any chance have a link to such documentation?
    – Tony
    Dec 3 at 1:35

up vote
2
down vote

accepted

up vote
2
down vote

accepted

Implementing the Kludge

If you really want to go the route of the workaround asking udev to re-evaluate its rules after AD/LDAP is reachable, then I guess my suggestion would be to use a dedicated service unit to run those udevadm commands.

Order that unit appropriately so that it runs after sssd.service is up (since that’s what’s querying your AD/LDAP backend) and also after network-online.target (to ensure it will be reachable, assuming sssd doesn’t have a cache of those users/groups yet) and before the service that needs those devices. (For illustration here, let’s assume it’s called oracle-asm.service.)

To do so, create a new service unit, such as /etc/systemd/system/asm-device-ownership.service with contents such as:

[Unit]
Description=Update ownership of Oracle ASM devices
After=sssd.service network-online.target
Before=oracle-asm.service

[Service]
Type=oneshot
ExecStart=/bin/udevadm control --reload
ExecStart=/bin/udevadm trigger --settle ... (your devices here) ...

[Install]
WantedBy=multi-user.target

Once that unit is in place, make systemd aware of it with command sudo systemctl daemon-reload and enable it with sudo systemctl enable asm-device-ownership.service.

Also notice I’m recommending using udevadm trigger --settle, in order to make that command synchronous. You want to make sure the operation is waited for, since the systemd ordering will ensure this service unit (setting up ownership of those devices) is finished before the one that depends on it (the one using the ASM devices) will start.

This should work, but there are a lot of moving parts at early reboot and reloading udev and retriggering rules in the middle of it might prove to have issues… So if you go this route, make sure you test this setup enough to make sure it’s actually reliable.


Having said that, I really recommend against using this kludge.

Instead, consider one of the alternative solutions below:

Replicating user/group locally

In the comments, I had previously recommended creating the same users locally, as described in this article in the Arch Linux wiki.

There’s not really much of a problem in having the user in both local /etc/passwd and /etc/group and also in AD/LDAP, considering the definitions in AD/LDAP will not change (but then, if they do change, you will probably have trouble anyways, particularly with the systems that are already running.)

I can see one problem with the local copy, which is if you want to manage the members of the asmadmin group on AD/LDAP and that information is likely to actually change (so duplicating it in local /etc/group is a problem.)

It turns out glibc 2.24 has a solution for that, by specifying that entries should be merged in /etc/nsswitch.conf:

passwd: files sssd
group:  files [SUCCESS=merge] sssd

(See the man page for nsswitch.conf for details on [SUCCESS=merge].)

But this option has some drawbacks:

  • The nsswitch.conf option to merge entries is only available starting on glibc 2.24, which is fairly recent. For instance, RHEL 7 ships version 2.17, so that’s not available there.
  • The “merge” feature is not perfect, the man page for instance describes how it doesn’t work with getgrent which is used to list all groups…
  • Using “merge” means sssd will be attempted for resolution even for groups which are present in local files! This potentially means longer delays in early boot, before sssd is actually up… (In fact, most of the solutions involving replicating users/groups locally are trying to solve the problems of the timeouts before the external services are available.)

So perhaps a better solution is:

Encode numeric UID/GID in udev configuration instead!

As mentioned before, I expect your user grid will have a fixed UID which will not change in time (since changing it during system operation would likely create more problems) and same for GID of asmadmin.

If that’s indeed the case, if you can rely on that UID and GID being fixed and dedicated, then consider encoding those in the udev rule, which can take numeric UIDs and GIDs in the OWNER and GROUP fields.

For example, if grid has UID 501 and asmadmin has GID 601, then use the following rule instead:

ENV{DM_UUID}=="<dm_uuid>", SYMLINK+="oracleasm/asmsysdga", OWNER="501", GROUP="601", MODE="0660"

This way, no user/group resolution is needed early in boot when udev is setting up these devices, but then when user/group resolution from AD/LDAP is available, the ownership will be correctly set for ASM to work with those devices.

That’s probably the best solution for this problem, really no significant drawbacks there.

share|improve this answer

Implementing the Kludge

If you really want to go the route of the workaround asking udev to re-evaluate its rules after AD/LDAP is reachable, then I guess my suggestion would be to use a dedicated service unit to run those udevadm commands.

Order that unit appropriately so that it runs after sssd.service is up (since that’s what’s querying your AD/LDAP backend) and also after network-online.target (to ensure it will be reachable, assuming sssd doesn’t have a cache of those users/groups yet) and before the service that needs those devices. (For illustration here, let’s assume it’s called oracle-asm.service.)

To do so, create a new service unit, such as /etc/systemd/system/asm-device-ownership.service with contents such as:

[Unit]
Description=Update ownership of Oracle ASM devices
After=sssd.service network-online.target
Before=oracle-asm.service

[Service]
Type=oneshot
ExecStart=/bin/udevadm control --reload
ExecStart=/bin/udevadm trigger --settle ... (your devices here) ...

[Install]
WantedBy=multi-user.target

Once that unit is in place, make systemd aware of it with command sudo systemctl daemon-reload and enable it with sudo systemctl enable asm-device-ownership.service.

Also notice I’m recommending using udevadm trigger --settle, in order to make that command synchronous. You want to make sure the operation is waited for, since the systemd ordering will ensure this service unit (setting up ownership of those devices) is finished before the one that depends on it (the one using the ASM devices) will start.

This should work, but there are a lot of moving parts at early reboot and reloading udev and retriggering rules in the middle of it might prove to have issues… So if you go this route, make sure you test this setup enough to make sure it’s actually reliable.


Having said that, I really recommend against using this kludge.

Instead, consider one of the alternative solutions below:

Replicating user/group locally

In the comments, I had previously recommended creating the same users locally, as described in this article in the Arch Linux wiki.

There’s not really much of a problem in having the user in both local /etc/passwd and /etc/group and also in AD/LDAP, considering the definitions in AD/LDAP will not change (but then, if they do change, you will probably have trouble anyways, particularly with the systems that are already running.)

I can see one problem with the local copy, which is if you want to manage the members of the asmadmin group on AD/LDAP and that information is likely to actually change (so duplicating it in local /etc/group is a problem.)

It turns out glibc 2.24 has a solution for that, by specifying that entries should be merged in /etc/nsswitch.conf:

passwd: files sssd
group:  files [SUCCESS=merge] sssd

(See the man page for nsswitch.conf for details on [SUCCESS=merge].)

But this option has some drawbacks:

  • The nsswitch.conf option to merge entries is only available starting on glibc 2.24, which is fairly recent. For instance, RHEL 7 ships version 2.17, so that’s not available there.
  • The “merge” feature is not perfect, the man page for instance describes how it doesn’t work with getgrent which is used to list all groups…
  • Using “merge” means sssd will be attempted for resolution even for groups which are present in local files! This potentially means longer delays in early boot, before sssd is actually up… (In fact, most of the solutions involving replicating users/groups locally are trying to solve the problems of the timeouts before the external services are available.)

So perhaps a better solution is:

Encode numeric UID/GID in udev configuration instead!

As mentioned before, I expect your user grid will have a fixed UID which will not change in time (since changing it during system operation would likely create more problems) and same for GID of asmadmin.

If that’s indeed the case, if you can rely on that UID and GID being fixed and dedicated, then consider encoding those in the udev rule, which can take numeric UIDs and GIDs in the OWNER and GROUP fields.

For example, if grid has UID 501 and asmadmin has GID 601, then use the following rule instead:

ENV{DM_UUID}=="<dm_uuid>", SYMLINK+="oracleasm/asmsysdga", OWNER="501", GROUP="601", MODE="0660"

This way, no user/group resolution is needed early in boot when udev is setting up these devices, but then when user/group resolution from AD/LDAP is available, the ownership will be correctly set for ASM to work with those devices.

That’s probably the best solution for this problem, really no significant drawbacks there.

share|improve this answer

share|improve this answer

share|improve this answer

answered Nov 30 at 3:27

Filipe Brandenburger

6,7551732

6,7551732

  • Thanks, I did not know that that rule also takes UID/GID. I don’t necessarily want to implement a kludge, which is why I posted the question, failing to find any comprehensive documentation on either udevd (and it’s rules) or systemd. Do you by any chance have a link to such documentation?
    – Tony
    Dec 3 at 1:35

  • Thanks, I did not know that that rule also takes UID/GID. I don’t necessarily want to implement a kludge, which is why I posted the question, failing to find any comprehensive documentation on either udevd (and it’s rules) or systemd. Do you by any chance have a link to such documentation?
    – Tony
    Dec 3 at 1:35

Thanks, I did not know that that rule also takes UID/GID. I don’t necessarily want to implement a kludge, which is why I posted the question, failing to find any comprehensive documentation on either udevd (and it’s rules) or systemd. Do you by any chance have a link to such documentation?
– Tony
Dec 3 at 1:35

Thanks, I did not know that that rule also takes UID/GID. I don’t necessarily want to implement a kludge, which is why I posted the question, failing to find any comprehensive documentation on either udevd (and it’s rules) or systemd. Do you by any chance have a link to such documentation?
– Tony
Dec 3 at 1:35

draft saved
draft discarded

Thanks for contributing an answer to Unix & Linux Stack Exchange!

  • Please be sure to answer the question. Provide details and share your research!

But avoid

  • Asking for help, clarification, or responding to other answers.
  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

Some of your past answers have not been well-received, and you’re in danger of being blocked from answering.

Please pay close attention to the following guidance:

  • Please be sure to answer the question. Provide details and share your research!

But avoid

  • Asking for help, clarification, or responding to other answers.
  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin(‘.new-post-login’, ‘https%3a%2f%2funix.stackexchange.com%2fquestions%2f484807%2fneed-udev-to-set-device-ownership-with-ad-ldap-users-and-groups-after-sssd-start%23new-answer’, ‘question_page’);
}
);

Post as a guest

Required, but never shown

Required, but never shown

Required, but never shown

Required, but never shown

Required, but never shown

Required, but never shown

Required, but never shown

Required, but never shown

Required, but never shown

Related Post

Leave a Reply

Your email address will not be published. Required fields are marked *