Cannot access cockpit Web UI (port 9090)

New NethServer was perfectly accessible over VPN. There was no problem on that. At some point it just become not accessible (for more than one fresh installation) even then I could still access it over SSH.

When I check, 9090 port was not listened. Moreover, there were some “dead” status for cockpit service as I shared above.

I do not think it is old server was not allowed to access situation here. I have no idea what was the problem either.

2 Likes

cockpit down, but I do not know why

I created an AWS instance to put a nethserver in Amazon Web Services

When I try to access to port 22 or 980 from red it works perfectly. But when I try to access to port 9090, it works or not depending of the IP. I read that shorewall firewall only works on IPv4. Maybe is transparent for IPv6 addresses?

So, Why ShoreWall is blocking cockpit (9090) on red?
I see that there is network services defined for 980 and 22 (or 2221), but I cannot see a network service defined for cockpit 9090 to put a rule and open it in shorewall for red.

The default configuration for port 9090 should be the same than for 980 or 2221 right? Access opened from everywhere on Internet.

Even I see a rule in shorewall to open port 9090 into my computer (static IP) used when I installed nethserver. Why is my IP there? That could be it’s enabled only access to 9090 port to my computer

More specifically:
Nethserver uses template /etc/e-smith/templates/etc/shorewall/rules/70cockpit

#
# 60cockpit
#
?COMMENT cockpit
{
    my $port = '9090';
    my $access = ${'cockpit.socket'}{'access'} || 'green';
    my $limit = ${'cockpit.socket'}{'LimitAccess'} || '';

    if ($limit ne '') {
        $limit = ":$limit";
    }
    if ($access =~ 'green') {
        $OUT .= "ACCEPT\tloc\t\$FW\ttcp\t$port\n";
    }
    if ($access =~ 'red') {
        $OUT .= "ACCEPT\tnet$limit\t\$FW\ttcp\t$port\n";
    }
}

to build in /etc/shorewall/rules

# previous rules...

#
# 60cockpit
#
?COMMENT cockpit
ACCEPT  loc     $FW     tcp     9090
ACCEPT  net:xxx.xxx.xxx.xxx        $FW     tcp     9090 # I removed my static IP

# ... more rules

The patch for my nethserver is:

When I added after this block (or added as template) this

#
# 65mycockpit
#
?COMMENT mycockpit
ACCEPT loc      $FW     tcp     9090
ACCEPT net      $FW     tcp     9090

Allows to me to access cockpit from everywhere.

I hope that helps
Best regards

3 Likes

Hum, cockpit available on red is default IIRC, strange

Could be related with the fact that Cockpit network service didn’t appear in :9090/nethserver#/services

My nethserver installation was made on June 22, 2020 at 8:54:30 AM
I applied a few updates from them. Maybe is something that was an issue at time of my setup and now is fixed.

If you want more info, I am pleased to give it to you. My previous post just want to address where to watch for other users.

In /etc/e-smith/templates/etc/shorewall/rules/70cockpit the comment has 60cockpit instead 70cockpit
and the following lines appear that is green the default interface:

my $access = ${'cockpit.socket'}{'access'} || 'green';
my $limit = ${'cockpit.socket'}{'LimitAccess'} || '';

Best regards

2 Likes

we have an issue today about nethserver with an kernel panic (on logs) all school internet went down…
i have made those steps and it worked with reassigning ip address into lan and fixed wan ip address also to…at first we didn’t had the webgui so we reinstalled cockpit with other troubleshooting it worked…do you know what is the cause of that… also i have updated

Please share relevant log entries…

Maybe you hit this one?

Romain S is my friend is at the school is managing right now with nethserver, he gonna sent you the logs mark

1 Like

Hello,

here are the logs you’ve been asking for :

September 25, 2020

11:04

pam_listfile(cockpit:auth): Refused user root for service cockpit

cockpit-session

10:29

hid-generic 0003:413C:2005.0001: usb_submit_urb(ctrl) failed: -19

kernel

10:23

ebpf.plugin should either run as root (now running with uid 981, euid 981) or have special capabilities…

ebpf.plugin

10:23

PROCFILE: Cannot open file ‘/etc/netdata/apps_groups.conf’

ebpf.plugin

10:23

Got sig[15] terminate (is_parent=0)

winbindd

10:23

[2020/09/25 10:23:18.439273, 0] …/…/source3/winbindd/winbindd.c:243(winbindd_sig_term_handler)

winbindd

10:23

Got sig[15] terminate (is_parent=0)

winbindd

10:23

[2020/09/25 10:23:18.437029, 0] …/…/source3/winbindd/winbindd.c:243(winbindd_sig_term_handler)

winbindd

10:23

Got sig[15] terminate (is_parent=0)

winbindd

10:23

[2020/09/25 10:23:18.436883, 0] …/…/source3/winbindd/winbindd.c:243(winbindd_sig_term_handler)

winbindd

10:23

Got sig[15] terminate (is_parent=1)

winbindd

10:23

[2020/09/25 10:23:18.436835, 0] …/…/source3/winbindd/winbindd.c:243(winbindd_sig_term_handler)

winbindd

10:23

Got SIGTERM: going down…

nmbd

10:23

[2020/09/25 10:23:15.748848, 0] …/…/source3/nmbd/nmbd.c:59(terminate)

nmbd

10:20

ebpf.plugin should either run as root (now running with uid 981, euid 981) or have special capabilities…

ebpf.plugin

10:20

PROCFILE: Cannot open file ‘/etc/netdata/apps_groups.conf’

ebpf.plugin

10:13

ebpf.plugin should either run as root (now running with uid 981, euid 981) or have special capabilities…

ebpf.plugin

10:13

PROCFILE: Cannot open file ‘/etc/netdata/apps_groups.conf’

ebpf.plugin

10:13

ebpf.plugin should either run as root (now running with uid 981, euid 981) or have special capabilities…

ebpf.plugin

10:13

PROCFILE: Cannot open file ‘/etc/netdata/apps_groups.conf’

ebpf.plugin

10:11

ebpf.plugin should either run as root (now running with uid 981, euid 981) or have special capabilities…

ebpf.plugin

10:11

PROCFILE: Cannot open file ‘/etc/netdata/apps_groups.conf’

ebpf.plugin

10:07

ebpf.plugin should either run as root (now running with uid 981, euid 981) or have special capabilities…

ebpf.plugin

10:07

PROCFILE: Cannot open file ‘/etc/netdata/apps_groups.conf’

ebpf.plugin

09:48


nmbd

09:48

nmbd

09:48

Samba name server SERVEUR is now a local master browser for workgroup EDUCASUISSE on subnet 192.168.176.2

nmbd

09:48

nmbd

09:48


nmbd

09:48

[2020/09/25 09:48:41.799546, 0] …/…/source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)

nmbd

09:44

; main; rspamd_control_broadcast_cmd: cannot write command 9(408) to the worker 2770(rspamd_proxy), fd: 11: Broken pipe

rspamd

09:44

<33c539>; upstreams; rspamd_resolve_addrs: address resolution for fuzzy1.rspamd.com failed: Name or service not known

rspamd

09:40

pam_listfile(cockpit:auth): Refused user root for service cockpit

cockpit-session

09:32

e1000e 0000:00:1f.6 eno1: Reset adapter unexpectedly

kernel

09:32

e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang: TDH <56> TDT <9d> next_to_use <9d> next_to_clean <55> buffer_info[next_to_clean]: time_stamp <10000ab0f> next_to_watch <57> jiffies <10000c22c> next_to_watch.status <0> MAC Status <80083> PHY Status <796d> PHY 1000BASE-T Status <3c00> PHY Extended Status <3000> PCI Status <10>

kernel

09:32

e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang: TDH <56> TDT <9d> next_to_use <9d> next_to_clean <55> buffer_info[next_to_clean]: time_stamp <10000ab0f> next_to_watch <57> jiffies <10000ba5c> next_to_watch.status <0> MAC Status <80083> PHY Status <796d> PHY 1000BASE-T Status <3c00> PHY Extended Status <3000> PCI Status <10>

kernel

09:32

e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang: TDH <56> TDT <9d> next_to_use <9d> next_to_clean <55> buffer_info[next_to_clean]: time_stamp <10000ab0f> next_to_watch <57> jiffies <10000b28c> next_to_watch.status <0> MAC Status <80083> PHY Status <796d> PHY 1000BASE-T Status <3c00> PHY Extended Status <3000> PCI Status <10>

kernel

09:28


nmbd

09:28

nmbd

09:28

Samba name server SERVEUR is now a local master browser for workgroup EDUCASUISSE on subnet 192.168.177.1

nmbd

09:28

nmbd

09:28


nmbd

09:28

[2020/09/25 09:28:10.443215, 0] …/…/source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)

nmbd

09:28


nmbd

09:28

nmbd

09:28

Samba name server SERVEUR is now a local master browser for workgroup EDUCASUISSE on subnet 192.168.176.10

nmbd

09:28

nmbd

09:28


nmbd

09:28

[2020/09/25 09:28:10.443103, 0] …/…/source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)

nmbd

09:27

ebpf.plugin should either run as root (now running with uid 981, euid 981) or have special capabilities…

ebpf.plugin

09:27

PROCFILE: Cannot open file ‘/etc/netdata/apps_groups.conf’

ebpf.plugin

09:27

daemon_ready: daemon ‘smbd’ finished starting up and ready to serve connections

smbd

09:27

[2020/09/25 09:27:53.010085, 0] …/…/lib/util/become_daemon.c:136(daemon_ready)

smbd

09:27

<>; ; rspamd_srv_request_handler: cannot read from server pipe: Resource temporarily unavailable

rspamd

09:27

daemon_ready: daemon ‘winbindd’ finished starting up and ready to serve connections

winbindd

09:27

[2020/09/25 09:27:47.384642, 0] …/…/lib/util/become_daemon.c:136(daemon_ready)

winbindd

09:27

initialize_winbindd_cache: clearing cache and re-creating with version number 2

winbindd

09:27

[2020/09/25 09:27:47.372983, 0] …/…/source3/winbindd/winbindd_cache.c:3166(initialize_winbindd_cache)

winbindd

09:27

daemon_ready: daemon ‘nmbd’ finished starting up and ready to serve connections

nmbd

09:27

[2020/09/25 09:27:47.004348, 0] …/…/lib/util/become_daemon.c:136(daemon_ready)

nmbd

09:27

mei_wdt mei::05b79a6f-4628-4d7f-899d-a91514cb32ab:02: Could not register event ret=-22

kernel

09:27

kvm: disabled by bios
kernel
|

1 Like

as critical and bellow event also we had :

pam_listfile(cockpit:auth): Refused user root for service cockpit

he as an nsdc (nethserver domain controller on it that is not used we dont need then on the routeur on if…) do you think (dumb question)

Thanks for the logs.

I think this is the problem. Maybe a hardware problem on network card?

Do you use proxmox?

Sorry, I don’t understand, please reformulate…

1 Like

no we use physical pc as router (nethserver)

ahhh do you think is the network card ?? i saw also that on log…now that you mentioned it …

That’s ok.

Yes, from the logs the network card e1000 has hang issues.

we will replace that card and rebuild the configs …that sucks :slight_smile: because is in prod we gonna make an 2nd nethserver, with 2 cards and restore configs from the first nethserver

thank you very much mark, you re the guy:)

1 Like

Before changing the Intel e1000 network card you could try to disable its advanced segmentation offload features.
From our experience, it solves the problem.

db networks setprop eno1 ethtool_opts "\"-K \${DEVICE} tso off\""
signal-event interface-update
6 Likes

Romain will gonna test that

Thanks you guys

1 Like

Thank you very much

1 Like

Thanks, we’re going to try that !

1 Like