Admin-todos and httpd ERRORS

Support
, , ,
1

NethServer Version: 7 Final
Module: admin, UI

I’m seeing frequent errors in the log. They don’t appear to cause any issues, other than a flash of red at the top of the UI. The ones I’m seeing are:

admin-todos: Connection refused
admin-todos: [ERROR] admin-todos: /etc/nethserver/todos.d/20admin-user exit code 9
httpd: [ERROR] Connection refused
httpd: [ERROR] NethServer\Tool\GroupProvider: Account provider connection refused

The exit code 9 message is mainly for the one above, but has also been seen for other scripts in the directory.

Hopefully I transcripted those correctly as I can’t cut/paste between the servers.

Cheers.

2

It seems the server manager fails to contact the accounts provider. Can you see users and groups listings? What does the Domain accounts page show?

3

Hmmm. The Users and Groups page now show as Empty.

Here’s the Domain Accounts:

blob.jpg721×493 114 KB

I wonder if this started when I update the Admin password, as the yellow “nag” suggested.

Cheers.

4

Update: No, at least some of these messages were appearing before I updated the admin password.

I see the “exit code 9” ones prior, but not the “Connection refused”.

Cheers.

5

Any ideas why. Could it have been when I updated the “admin” password.

How do I get things back in sync again.

Cheers.

6

Could you paste here the output of

account-provider-test dump
7 
[root@Nethserver ~]# account-provider-test dump
{
   "startTls" : "",
   "bindUser" : "NETHSERVER$",
   "userDN" : "dc=BogoLinux,dc=net",
   "port" : 636,
   "isAD" : "1",
   "host" : "BogoLinux.net",
   "groupDN" : "dc=BogoLinux,dc=net",
   "isLdap" : "",
   "ldapURI" : "ldaps://BogoLinux.net",
   "baseDN" : "dc=BogoLinux,dc=net",
   "bindPassword" : "Z6q@ApqgWZ<ds7",
   "bindDN" : "DISCWORLD\\NETHSERVER$"
}
[root@Nethserver ~]#

Cheers.

8

I have no idea about the reason of “connection refused”!

  • the local accounts provider is running
  • simple LDAP binds seem configured at their default values

In the past I got the same error for SSL certificates problems…

You could try to disable SSL:

config setprop sssd LdapURI ldap://$(config getprop nsdc IpAddress)
config show sssd
9 
[root@Nethserver ~]# config setprop sssd LdapURI ldap://$(config getprop nsdc IpAddress)
[root@Nethserver ~]# config show sssd
sssd=service
    AdDns=192.168.0.253
    LdapURI=ldap://192.168.0.253
    Provider=ad
    status=enabled
[root@Nethserver ~]#

OK, now that appears to have resolved it. I can now see my Users and Groups again, and I don’t see the errors, so far.

One of the early tasks I did was to re-generate the Server Certificate. Could this not have propagated correctly.

Cheers.

1 Like
10

Could you describe the procedure you applied?

Is nsdc the only DC of the AD domain?

11

All I did was go to the Server Certificate page on the UI and selected “Edit self-signed certificate” from the pull-down menu at the top of the page.

Yes, this is a stand-alone NS.

Cheers.

1 Like
12

I ran one of the earlier commands you asked again:

[root@Nethserver ~]# account-provider-test dump
{
   "startTls" : "",
   "bindUser" : "NETHSERVER$",
   "userDN" : "dc=BogoLinux,dc=net",
   "port" : 389,
   "isAD" : "1",
   "host" : "192.168.0.253",
   "groupDN" : "dc=BogoLinux,dc=net",
   "isLdap" : "",
   "ldapURI" : "ldap://192.168.0.253",
   "baseDN" : "dc=BogoLinux,dc=net",
   "bindPassword" : "Z6q@ApqgWZ<ds7",
   "bindDN" : "DISCWORLD\\NETHSERVER$"
}
[root@Nethserver ~]#

I can see that, yes, it’s disabled SSL now. But the ldapURI now points to the IP for the DC. However, the previous display, with SSL, shows a host name, not an IP. But that host name resolves to the host, not the IP for the DC. Could that be the issue ??

Cheers.

1 Like
13

Another interesting observation. The property ldapURI was empty, prior to the update you asked for:

Mar 14 11:22:17 Nethserver /sbin/e-smith/db[20719]: /var/lib/nethserver/db/configuration: OLD sssd=service|AdDns|192.168.0.253|LdapURI||Provider|ad|status|enabled
Mar 14 11:22:17 Nethserver /sbin/e-smith/db[20719]: /var/lib/nethserver/db/configuration: NEW sssd=service|AdDns|192.168.0.253|LdapURI|ldap://192.168.0.253|Provider|ad|status|enabled

Cheers.

14

OK, this is still causing me grief. I’m now seeing this trying to navigate to the User and Group page:

Mar 19 17:38:39 Nethserver httpd: [ERROR] NethServer\Tool\UserProvider: AccountProvider_Error_113
Mar 19 17:38:39 Nethserver httpd: [ERROR] No route to host

And trying to log on to a new session in the UI:

Mar 19 17:40:57 Nethserver httpd: [WARNING] NethServer\Tool\GroupProvider: Account provider connection timed out
Mar 19 17:40:57 Nethserver httpd: [WARNING] Connection timed out

Which just results in a blank screen.

Cheers.

15
  • IP conflict?
  • nsdc down?
  • bridge removed?

From server manager, go to “Status > Domain accounts” page.

From command line:

 systemctl status nsdc
16

I’m currently laid up in bed with the cough/cold from hell.

I’ll respond more when I’m up an about again, but I know exactly what
happened with the latest messages and also have (yet another) theory about
what might have caused the original ones.

Cheers.

1 Like
17

OK. For the last set of errors, it was exactly as described by @davidep. Here’s what happened:

I built a new NS7 system, on a real hard drive, attached to my ESXi server so that when it was complete and I was ready to move from NS6 → NS7 all I needed to do was shut down NS6, swap drives and re-boot. I’d already asked a question as to how to manage the change in interface names that was going to happen. What I didn’t expect to happen was that when I booted NS7 for the first time, it updated the Bridge interface in the networks DB from br0 to brdef (I think). No big deal, I thought, as long as it still bridges to my internal network NIC. Haha, how wrong was that. There are other references to that bridge name in the configuration files. One of them I knew of, and had already reset the DHCP server to run off the updated name. What I didn’t know was that the nsdc service also relies on that name, but that doesn’t show up in any configuration pages, so initially I didn’t think there was anything else to update. Bottom line, resetting my bridge interface back to the automatically chosen name from the Account Provider set-up cured all.

I guess a couple of takeaways from that. Why did booting in a new environment rename the bridge in the first place. Why does that default name differ from the default name chosen by the Account Provider. And why doesn’t the “interface-update” event ensure that interfaces required by other services are “present and correct” before updating the configuration.

Now, back to my original issue:

BUT at the time, I did not re-select the “Set as default” button. Could that have caused it.

Cheers.

18

That happens when the green interfaces names change:

  • If only one interface is present the rename operation is triggered automatically.
  • If two or more new and unassigned interfaces are found brdef (green) is created. The Network page should ask to remap old names to new ones.

In any case, services should not need to change their configuration after old interface names are restored.

This kind of check is performed by the restore procedure.

It’s not clear to me how did you swap ns6/ns7 hard drives, but I guess that procedure didn’t run!

19

I, kind of, described it in my question in this post. After swapping the disk, I had to manually update the Networks DB. That was when I noticed the bridge name change, which as I said, I didn’t think mattered other than as a “link” between the real NIC and the Green interface.

Cheers.

1 Like