hello
i have 3 UCS as VM over Proxmox, Proxmox got a update and reboot.
after this the 3 UCS are not reachable.
i had to reboot them again, so the ucs with management would run but no access to the UCS-VM with nextcloud/onlyoffice.
so why this?
it say to also
More details can be found in the server log.
which log should be checked?
and how to install multitail ?
have a nice day
vinc
hello again
it’s fun (sarcastic), each time i reboot my Proxmox server because of a update.
The VM with ucs is booting back but no GUI is loading when entering the IP Adress, each time i have to reboot the ucsVM a second time, then it works.
and then also the second ucsVM with nextcloud have to be rebootet because the ucs among themselves can’t reconect
have a nice day
vinc
there is not much help or support. what should be done if i ucs do reboot but can’t reach and get some inter error on the same server?
Where to dig for information?
This time also after multiple reboot i still got a ERR_CONNECTION_REFUSED
Seems like the VM’s might have moved the ip address after the reboot.
I can assure you that this works on VM , but the VM MUST have a FIXED ip address internally and it must NOT move…, since may internal settings are tied to ip addresses rather than resolvable FQDN
@talleyrand hello thanks for you feedback.
All my VM have fixed IP - and yes i also work with fix IP and not the FQDN too.
with
systemctl --type=service
i also found out that some service did not start.
doing a systemclt start “the Service” it worked again after this
have a nice day
vinc
Did you try setting the “start/shutdown order” settings in PVE? You can set a delay. Maybe the network isn’t yet ready when the VMs boot.
Are the services enabled?
@MasinAD-SI
should be yes, it is a UCS Default installation.
and today
the UCS Gui is there to login:
Interner Server-Fehler: Der Dienst ist momentan nicht erreichbar!
The Univention Management Console Web Server could not be reached. Please restart it or try again later.
strange because it is localhost to reach!
ssh to the UCS system and doing a
systemctl --type=service
give a
univention-management-console-web-server.service loaded failed failed LSB: Univention Management Console Web Server
doing a
# systemctl start univention-management-console-web-server.service
takes a whil to execute but after it is loaded active running
but then
systemctl --type=service
? univention-s4-connector.service **loaded failed failed** LSB: Univention S4 Connector
again doing a start take a while then it is there but the status say:
Sep 15 17:06:30 ucs01-mgmt1 systemd[1]: univention-s4-connector.service: Supervising process 13710 which is not our child. We'll most likely not notice when it exits.
and in the GUI there is no login file anymore just the Portal background image - with no option to login and no visible app
done again a reboot of the ucs - and
WHY This happen?
# systemctl --state=failed
UNIT LOAD ACTIVE SUB DESCRIPTION
? apache2.service loaded failed failed The Apache HTTP Server
? postgresql@9.6-main.service loaded failed failed PostgreSQL Cluster 9.6-main
? univention-management-console-web-server.service loaded failed failed LSB: Univention Management Console Web Server
? univention-s4-connector.service loaded failed failed LSB: Univention S4 Connector
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
4 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
go into “univention cofiguration registry” on the web page…
check things like:
connector/ad/ldap/host/
connector/ad/mapping/kerboshdomain
etc
anything else that resolves via “FQDN”
then check all other adresses are sensible
dns/forwarder
gateway
etc
Also check that the network cards in your VM are resolving correctly
I remember some vm’s allocate the network cards out of sequence on older versions, depending on what gets picked up first… linux assumed they always came up in the same sequence… which they might not… (so start with only 1 virtual NIC)
hello
i will check the
it should be the IP Adresse because my UCS is behind a firewall.
doing a
systemctl start .... * service
did start it and worked so far. will check it later again…
When you issue the command systemctl status univention-management-console.service you should see the last few lines of its log. You can procede accordingly with the other failed services.
At the moment I suspect that the apache2.service fails and successively all the dependent services.
Please post the output of the systemctl status <service> command.
This tells you WHAT failed but NOT why. ESP. if you are “natting”
this depends on your VM…
some VM give an IP address IN the current address space,
other NAT it, so the internal VM< has a different IP address than what is actually shown on the outside of the VM.
so internally your VM might have NICs saying 192.168.0.5/24 ,
but the outside of the VM might show. 172.16.11.5/24
so you have to be REAL careful with your DNS & FQDN so they map to the OUTSIDE of the vm, but then you NAT to the internal ip’s
and internal services map to 127.0.0.1 , but again you have to be real careful that services are not just bound to the NIC address…