New Server Manager cannot get to work

NethServer Version: V7
Module: server manager

Hello again :smile:
I am trying to get the new server manager working on 2nd nethserver and am unable to do so.

I installed same as in 1st nethserver and enabled the service as i noticed it was not running as the first.
systemctl status cockpit
ā— cockpit.service - Cockpit Web Service
Loaded: loaded (/usr/lib/systemd/system/cockpit.service; static; vendor preset: disabled)
Active: inactive (dead)
Docs: man:cockpit-ws(8)
You have new mail in /var/spool/mail/root
[root@ad2 log]# systemctl start cockpit
[root@ad2 log]# systemctl status cockpit
ā— cockpit.service - Cockpit Web Service
Loaded: loaded (/usr/lib/systemd/system/cockpit.service; static; vendor preset: disabled)
Active: active (running) since Tue 2019-11-12 08:13:30 EST; 1s ago
Docs: man:cockpit-ws(8)
Process: 4840 ExecStartPre=/usr/sbin/remotectl certificate --ensure --user=root --group=cockpit-ws --selinux-type=etc_t (code=exited, status=0/SUCCESS)
Main PID: 4855 (cockpit-ws)
CGroup: /system.slice/cockpit.service
└─4855 /usr/libexec/cockpit-ws

Nov 12 08:13:30 … systemd[1]: Starting Cockpit Web Service…
Nov 12 08:13:30 … remotectl[4840]: Generating temporary certificate using: sscg --quiet --lifetime 3650 --key-stren…
Nov 12 08:13:30 … remotectl[4840]: Error generating temporary dummy cert using sscg, falling back to openssl
Nov 12 08:13:30 … remotectl[4840]: Generating temporary certificate using: openssl req -x509 -days 36500 -newkey rs…
Nov 12 08:13:30 … remotectl[4840]: /usr/bin/chcon: can’t apply partial context to unlabeled file ā€˜/etc/cockpi…ed.cert’
Nov 12 08:13:30… remotectl[4840]: remotectl: couldn’t change SELinux type context ā€˜etc_t’ for certificate: /…code 1
Nov 12 08:13:30 … systemd[1]: Started Cockpit Web Service.
Nov 12 08:13:30 … cockpit-ws[4855]: Using certificate: /etc/cockpit/ws-certs.d/0-self-signed.cert
Hint: Some lines were ellipsized, use -l to show in full.

Even shows on the main page in https://…:980
The new Server Manager is installed, give it a try! Access: https://ad2:9090

but never launches when clicked i get:
Unable to connect

Firefox can’t establish a connection to the server at ad2:9090.

Nmap shows the following:
Starting Nmap 7.60 ( https://nmap.org ) at 2019-11-12 08:18 EST
Nmap scan report for …
Host is up (0.00013s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http
443/tcp open https

Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds

Where the 1st server nmap shows:
Nmap scan report for …
Host is up (0.0027s latency).
Not shown: 989 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
465/tcp open smtps
587/tcp open submission
631/tcp open ipp
9090/tcp open zeus-admin

Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds

Even grepping the cockpit service shows different:
1st server:

systemctl |grep cockpit

cockpit.service loaded active running Cockpit Web Service
cockpit.socket loaded active running Cockpit Web Service Socket

Server i am having the issue on:

systemctl |grep cockpit

cockpit.socket loaded active listening Cockpit Web Service Socket

Any ideas where i should look? Thank you in advance :slight_smile:

A really win-doze-like way to get around the issue:

  • remove New Server Manager
  • yum clean all from shell
  • reboot your NethServer (only if do not have the latest kernel)
  • try again to install New Server Manager

Sorry, i never had this kind of issues…

Thank you Pike, i feel we are making progress, there was a new update for cockpit-libs which i updated.
Removed new server manager in software center. Performed yum clean all in console. Rebooted after installing via software center:

systemctl status cockpit

ā— cockpit.service - Cockpit Web Service
Loaded: loaded (/usr/lib/systemd/system/cockpit.service; static; vendor preset: disabled)
Active: inactive (dead)
Docs: man:cockpit-ws(8)

systemctl start cockpit

systemctl status cockpit

ā— cockpit.service - Cockpit Web Service
Loaded: loaded (/usr/lib/systemd/system/cockpit.service; static; vendor preset: disabled)
Active: active (running) since Tue 2019-11-12 09:33:17 EST; 2s ago
Docs: man:cockpit-ws(8)
Process: 3575 ExecStartPre=/usr/sbin/remotectl certificate --ensure --user=root --group=cockpit-ws --selinux-type=etc_t (code=exited, status=0/SUCCESS)
Main PID: 3589 (cockpit-ws)
CGroup: /system.slice/cockpit.service
└─3589 /usr/libexec/cockpit-ws

Nov 12 09:33:17 … systemd[1]: Starting Cockpit Web Service…
Nov 12 09:33:17 … remotectl[3575]: /usr/bin/chcon: can’t apply partial context to unlabeled file ā€˜/etc/cockpi…ed.cert’
Nov 12 09:33:17 … remotectl[3575]: remotectl: couldn’t change SELinux type context ā€˜etc_t’ for certificate: /…code 1
Nov 12 09:33:17 … systemd[1]: Started Cockpit Web Service.
Nov 12 09:33:17 … cockpit-ws[3589]: Using certificate: /etc/cockpit/ws-certs.d/0-self-signed.cert
Hint: Some lines were ellipsized, use -l to show in full.

systemctl |grep cockpit

cockpit.service loaded active running Cockpit Web Service
cockpit.socket loaded active running Cockpit Web Service Socket

However i still cannot connect to port 9090
Nov 12 09:34:03 ad2 kernel: Shorewall:loc2fw:REJECT:IN=bond0 OUT= MAC=…2f:46:08:00 SRC=… DST=… LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=4682 DF PROTO=TCP SPT=60534 DPT=9090 WINDOW=64240 RES=0x00 SYN URGP=0

could shorewall not be updated even though i installed via software center? how do i allow via shorewall?

Thank you :slight_smile:

Shorewall rules should be created automatically when installing cockpit.
Also, i have Cockpit installed on this setup, but no Firewall.
But…
Into NethGui (the current server manager) there are no references to Cockpit except the software manager.
Not into Status->services.
Not into Security-> network Services
But there is httpd-admin referring port 980 for NethGUI. Quite strange.

So maybe you can create a firewall rule that allow connection from the zone you’d like to use for managing your cockpit/New Server Manager

Thank you Pike, unfortunately, i have no idea how to add this to the shorewall config as it warns not to mess with the config. Im stumped. :frowning:

Latest update:
Added:

ACCEPT loc $FW tcp 9090
ACCEPT net $FW tcp 9090
to a new template in /etc/e-smith/templates-custom/etc/shorewall/rules/90newserver

which allows me to go to the webpage but it is bad wrong. Im not sure what to do here:
it says CentOs on the Top instead of Nethserver 7.7
There is the server name in the left side window but no menu options and the dashboard is broken. ?

Hope it’s o.k. to jump in.

There should be already a template/etc/e-smith/templates/etc/shorewall/rules/60cockpit.
=> cat /etc/e-smith/templates/etc/shorewall/rules/60cockpit

#
# 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";
    }
}

which sould do

#
# 60cockpit
#
?COMMENT cockpit
ACCEPT  loc     $FW     tcp     9090

in /etc/shorewall/rules.

If not try: expand-template /etc/shorewall/rules and signal-event firewall-adjust

1 Like

Thank you for jumping in :slight_smile:

the rules are on the 1st server but not the server in question.

60cockpit

?COMMENT cockpit
ACCEPT loc $FW tcp 9090
ACCEPT net $FW tcp 9090

that is from the 1st server

on the second server that we are talking about:
ad2 log]# ll /etc/e-smith/templates/etc/shorewall/rules/
total 48
-rw-r–r-- 1 root root 560 Oct 28 04:47 10base00header
-rw-r–r-- 1 root root 48 Oct 28 04:47 10base20established
-rw-r–r-- 1 root root 870 Oct 28 04:47 10base20established90nfq
-rw-r–r-- 1 root root 803 Oct 28 04:47 10base50related
-rw-r–r-- 1 root root 32 Oct 28 04:47 10base90new
-rw-r–r-- 1 root root 635 Oct 28 04:47 20ping
-rw-r–r-- 1 root root 251 Oct 28 04:47 30dns
-rw-r–r-- 1 root root 3076 Oct 28 04:47 50pf
-rw-r–r-- 1 root root 414 Nov 12 03:44 60cockpit
-rw-r–r-- 1 root root 1738 Oct 28 04:47 60rules
-rw-r–r-- 1 root root 2284 Oct 28 04:47 70services
-rw-r–r-- 1 root root 259 Oct 28 04:47 90dns_blue

@ad2 log]# cat /etc/e-smith/templates/etc/shorewall/rules/60cockpit

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";
}

}

commented my custom rules set and signal-even firewall-adjust then ran your commands. Now i show:

60cockpit

?COMMENT cockpit
ACCEPT loc $FW tcp 9090

60rules

and reloading the …:980 …then launching the …:9090 page it is still not correct:


and logging in shows it further not correct:

there are no menu options … nothing.
As on the 1st server:

thank you all for helping me out :slight_smile:

almost as if dependencies did not install with new-server manager ?

You can try if it works after reinstalling these packages:

yum reinstall nethserver-cockpit cockpit cockpit-{bridge,storaged,system,ws}
1 Like

Good morning Marc, i did as you advised and rebooted. The firewall rule is still there:

60cockpit

?COMMENT cockpit
ACCEPT loc $FW tcp 9090

60rules

But the port is not open:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:873 0.0.0.0:* LISTEN 1949/rsync
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1/systemd
tcp 0 0 0.0.0.0:273 0.0.0.0:* LISTEN 2417/stunnel
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 2374/dnsmasq
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2376/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 2379/cupsd
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 2939/master
tcp6 0 0 :::443 :::* LISTEN 2440/httpd
tcp6 0 0 :::873 :::* LISTEN 1949/rsync
tcp6 0 0 :::111 :::* LISTEN 1/systemd
tcp6 0 0 :::80 :::* LISTEN 2440/httpd
tcp6 0 0 :::980 :::* LISTEN 2394/httpd
tcp6 0 0 :::53 :::* LISTEN 2374/dnsmasq
tcp6 0 0 :::22 :::* LISTEN 2376/sshd
tcp6 0 0 ::1:631 :::* LISTEN 2379/cupsd
tcp6 0 0 :::25 :::* LISTEN 2939/master
udp 0 0 0.0.0.0:37649 0.0.0.0:* 1968/avahi-daemon:
udp 0 0 0.0.0.0:53 0.0.0.0:* 2374/dnsmasq
udp 0 0 0.0.0.0:69 0.0.0.0:* 2374/dnsmasq
udp 0 0 0.0.0.0:111 0.0.0.0:* 1/systemd
udp 0 0 0.0.0.0:123 0.0.0.0:* 2013/chronyd
udp 0 0 127.0.0.1:323 0.0.0.0:* 2013/chronyd
udp 0 0 0.0.0.0:835 0.0.0.0:* 1938/rpcbind
udp 0 0 0.0.0.0:5353 0.0.0.0:* 1968/avahi-daemon:
udp6 0 0 :::53 :::* 2374/dnsmasq
udp6 0 0 :::69 :::* 2374/dnsmasq
udp6 0 0 :::111 :::* 1/systemd
udp6 0 0 :::123 :::* 2013/chronyd
udp6 0 0 ::1:323 :::* 2013/chronyd
udp6 0 0 :::835 :::* 1938/rpcbind

If i start the cockpit service:

systemctl start cockpit

]# systemctl status cockpit
ā— cockpit.service - Cockpit Web Service
Loaded: loaded (/usr/lib/systemd/system/cockpit.service; static; vendor preset: disabled)
Active: active (running) since Thu 2019-11-14 08:21:16 EST; 5s ago
Docs: man:cockpit-ws(8)
Process: 4142 ExecStartPre=/usr/sbin/remotectl certificate --ensure --user=root --group=cockpit-ws --selinux-type=etc_t (code=exited, status=0/SUCCESS)
Main PID: 4156 (cockpit-ws)
CGroup: /system.slice/cockpit.service
└─4156 /usr/libexec/cockpit-ws

Nov 14 08:21:16 … systemd[1]: Starting Cockpit Web Service…
Nov 14 08:21:16 … remotectl[4142]: /usr/bin/chcon: can’t apply partial context to unlabeled file ā€˜/etc/cockpi…ed.cert’
Nov 14 08:21:16 … remotectl[4142]: remotectl: couldn’t change SELinux type context ā€˜etc_t’ for certificate: /…code 1
Nov 14 08:21:16 … systemd[1]: Started Cockpit Web Service.
Nov 14 08:21:16 … cockpit-ws[4156]: Using certificate: /etc/cockpit/ws-certs.d/0-self-signed.cert
Hint: Some lines were ellipsized, use -l to show in full.
]# systemctl |grep cockpit
cockpit.service loaded active running Cockpit Web Service
cockpit.socket loaded active running Cockpit Web Service Socket

and go to the webpage… it is still the same as above picture… no menus no info

Thank you for your help!

Perhaps there is something missing that cockpit serves?

On a working system it shall start without human intervention.

# systemctl is-enabled cockpit.socket
enabled
# systemctl is-enabled cockpit.service
static

Did you activated the service with:

systemctl enable cockpit

These messages usually are not be relevant (same warnings on a working system).


Did you installed NethServer on top of a CentOS base?


The working server is using bonded interfaces (like the non-working seems to use)?

Thank you for taking time to help.

]# systemctl is-enabled cockpit.service
static
]# systemctl is-enabled cockpit.socket
disabled
]# systemctl enable cockpit.socket
Created symlink from /etc/systemd/system/sockets.target.wants/cockpit.socket to /usr/lib/systemd/system/cockpit.socket.
]# systemctl is-enabled cockpit.socket
enabled

and no i had used the same iso i used with 1st server the nethserver iso: 7.6.1810-x86_64

yes both servers have bonded nics.

You’re probably right. Maybe a yum install/update ended abruptly resulting in a partial transaction or there are missing packages.

You can try if it makes any difference running:

yum update @nethserver-iso

Hi Marc i did as request and only was nethserver-phonehome. If i recall before the latest updates to cockpit on the 1st server i had to install additional ā€œstuffā€ to make cockpit work there.

Resolving Dependencies
–> Running transaction check
—> Package nethserver-phonehome.noarch 0:1.3.0-1.ns7 will be updated
—> Package nethserver-phonehome.noarch 0:1.4.0-1.ns7 will be an update
–> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================================================
Package Arch Version Repository Size

Updating:
nethserver-phonehome noarch 1.4.0-1.ns7 nethserver-updates 20 k

Transaction Summary

Upgrade 1 Package

one-liner command:

yum install nethserver-cockpit PackageKit PackageKit-{glib,yum} cockpit cockpit-{bridge,packagekit,storaged,system,ws} device-mapper-multipath device-mapper-multipath-libs dosfstools expect gdisk json-glib libatasmart glib-networking gsettings-desktop-schemas iscsi-initiator-utils iscsi-initiator-utils-iscsiuio libblockdev libblockdev-{crypto,fs,loop,lvm,mdraid,part,swap,utils} libbytesize libgudev1 libudisks2 mpfr perl-String-ShellQuote pygobject2 python-pwquality tcl udisks2 udisks2-{iscsi,lvm2} volume_key-libs nethserver-cockpit-lib

thank you for continuing to help me, i did this command as you wrote and it came back with:
Resolving Dependencies
–> Running transaction check
—> Package PackageKit-glib.x86_64 0:1.1.10-1.el7.centos will be installed
—> Package pygobject2.x86_64 0:2.28.6-11.el7 will be installed
–> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================================================
Package Arch Version Repository Size

Installing:
PackageKit-glib x86_64 1.1.10-1.el7.centos ce-base 127 k
pygobject2 x86_64 2.28.6-11.el7 ce-base 226 k

Transaction Summary

Install 2 Packages

Total download size: 354 k
Installed size: 1.3 M
Is this ok [y/d/N]:

Running transaction
Installing : PackageKit-glib-1.1.10-1.el7.centos.x86_64 1/2
Installing : pygobject2-2.28.6-11.el7.x86_64 2/2
Verifying : pygobject2-2.28.6-11.el7.x86_64 1/2
Verifying : PackageKit-glib-1.1.10-1.el7.centos.x86_64 2/2

Installed:
PackageKit-glib.x86_64 0:1.1.10-1.el7.centos pygobject2.x86_64 0:2.28.6-11.el7

rebooted the server and still shows Centos on the login screen, i log in with root and pass and still shows no menu:

almost as if its not pointing to a config? maybe a default config it is using? but not sure where to check the difference on 1st server compared to 2nd server. If this matters i have the 2nd server configured as hot spare slave.

more info:
when i put in the https://FQDN:9090
the screen i blank with only the windows for login.


when i put in the ip:9090 it is the centos login again.