I assume it was the VPN of the old Nethserver. I think you needed to add the “old” VPN network to the trusted networks of the new Nethserver to be able to access the server manager over VPN.
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.
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
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
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
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
|
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…
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 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:)
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
Romain will gonna test that
Thanks you guys
Thank you very much