Community Forum

Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

NEWS

Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨
B
Bluefox

17

1

3.4k
Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄
B
Bluefox

13

1

1.1k
Weihnachtsangebot 2025! 🎄
B
Bluefox

25

1

2.5k

[gelöst] USV an Proxmox in LXC durchreichen

Verschoben Proxmox

45 Beiträge 10 Kommentatoren 4.2k Aufrufe 9 Watching

D David G.

@wendy2702

# Network UPS Tools: example nut.conf
#
##############################################################################
# General section
##############################################################################
# The MODE determines which part of the NUT is to be started, and which
# configuration files must be modified.
#
# This file try to standardize the various files being found in the field, like
# /etc/default/nut on Debian based systems, /etc/sysconfig/ups on RedHat based
# systems, ... Distribution's init script should source this file to see which
# component(s) has to be started.
#
# The values of MODE can be:
# - none: NUT is not configured, or use the Integrated Power Management, or use
#   some external system to startup NUT components. So nothing is to be started.
# - standalone: This mode address a local only configuration, with 1 UPS
#   protecting the local system. This implies to start the 3 NUT layers (driver,
#   upsd and upsmon) and the matching configuration files. This mode can also
#   address UPS redundancy.
# - netserver: same as for the standalone configuration, but also need
#   some more network access controls (firewall, tcp-wrappers) and possibly a
#   specific LISTEN directive in upsd.conf.
#   Since this MODE is opened to the network, a special care should be applied
#   to security concerns.
# - netclient: this mode only requires upsmon.
#
# IMPORTANT NOTE:
#  This file is intended to be sourced by standard POSIX shell scripts (so
#  there is no guaranteed `export VAR=VAL` syntax) and by systemd on Linux.
#  You MUST NOT use spaces around the equal sign!

MODE=netserver

# Uncomment this to allow starting the service even if ups.conf has no device
# sections at the moment. This environment variable overrides the built-in
# "false" and an optional same-named default flag that can be set in upsd.conf:
#ALLOW_NO_DEVICE=true
#export ALLOW_NO_DEVICE

# Network UPS Tools: example ups.conf
#
# --- SECURITY NOTE ---
#
# If you use snmp-ups and set a community string in here, you
# will have to secure this file to keep other users from obtaining
# that string.  It needs to be readable by upsdrvctl and any drivers,
# and by upsd.
#
# ---
#
# This is where you configure all the UPSes that this system will be
# monitoring directly.  These are usually attached to serial ports, but
# USB devices and SNMP devices are also supported.
#
# This file is used by upsdrvctl to start and stop your driver(s), and
# is also used by upsd to determine which drivers to monitor.  The
# drivers themselves also read this file for configuration directives.
#
# The general form is:
#
# [upsname]
#       driver = <drivername>
#         port = <portname>
#       < any other directives here >
#
# The section header ([upsname]) can be just about anything as long as
# it is a single word inside brackets.  upsd uses this to uniquely
# identify a UPS on this system.
#
# If you have a UPS called snoopy, your section header would be "[snoopy]".
# On a system called "doghouse", the line in your upsmon.conf to monitor
# and manage it would look something like this:
#
#   MONITOR snoopy@doghouse 1 upsmonuser mypassword primary
#
# It might look like this if monitoring in "secondary" mode (without any
# ability to directly manage the UPS) from a different system:
#
#   MONITOR snoopy@doghouse 1 upsmonuser mypassword secondary
#
# Configuration directives
# ------------------------
#
# These directives are used by upsdrvctl only and should be specified outside
# of a driver definition:
#
#    maxretry: OPTIONAL.  Specify the number of attempts to start the driver(s),
#              in case of failure, before giving up. A delay of 'retrydelay' is
#              inserted between each attempt. Caution should be taken when using
#              this option, since it can impact the time taken by your system to
#              start.
#
#              The built-in default is 1 attempt.
#
#  retrydelay: OPTIONAL.  Specify the delay between each restart attempt of the
#              driver(s), as specified by 'maxretry'. Caution should be taken
#              when using this option, since it can impact the time taken by your
#              system to start.
#
#              The default is 5 seconds.
#
#      chroot: OPTIONAL. Used for securing. See man page for details.
#
#  driverpath: OPTIONAL. Used for custom setups. See man page for details.
#
#      nowait: OPTIONAL. Tell upsdrvctl to not wait at all for the driver(s)
#              to execute the requested command. Fire and forget.
#
# pollinterval: OPTIONAL. The status of the UPS will be refreshed after a
#              maximum delay which is controlled by this setting (default
#              2 seconds). This may be useful if the driver is creating too
#              much of a load on your system or network.
#              Note that some drivers also have an option called *pollfreq*
#              which controls how frequently some of the less critical
#              parameters are polled. See respective driver man pages.
#

# Set maxretry to 3 by default, this should mitigate race with slow devices:
maxretry = 3

# These directives can be set outside and inside a driver definition, with
# slightly different meanings per context:
#
# maxstartdelay: OPTIONAL.  This can be set as a global variable
#                above your first UPS definition and it can also be
#                set in a UPS section.  This value controls how long
#                upsdrvctl will wait for the driver to finish starting.
#                This keeps your system from getting stuck due to a
#                broken driver or UPS.
#                The default is 45 seconds.
#
#   debug_min: OPTIONAL.  Specify a minimum debug level for all driver daemons
#              (when specified at global level), or for this driver daemon
#              (when specified in a driver section), e.g. for troubleshooting
#              a deployment. This does not directly impact the foreground or
#              background running mode. If both the global and driver level
#              `debug_min` are set, the driver-level setting takes precedence.
#              Command-line option `-D` can only increase this verbosity level.
#
# user, group: OPTIONAL. Overrides the compiled-in (also global-section,
#                when used in driver section) default unprivileged user/group
#                name for NUT device driver. Impacts access rights used for
#                the socket file access (group) and communication ports (user).
#
# synchronous: OPTIONAL.  The driver work by default in asynchronous
#              mode (like *no*) with fallback to synchronous if sending
#              fails (i.e *synchronous=auto*).  This means that all data
#              are pushed by the driver on the communication socket to
#              upsd (Unix socket on Unix, Named pipe on Windows) without
#              waiting for these data to be actually consumed.  With
#              some HW, such as ePDUs, that can produce a lot of data,
#              asynchronous mode may cause some congestion, resulting in
#              the socket to be full, and the driver to appear as not
#              connected.  By enabling the 'synchronous' flag
#              (value = 'yes'), the driver will wait for data to be
#              consumed by upsd, prior to publishing more.  This can be
#              enabled either globally or per driver.
#
#              The default is 'no' (i.e. asynchronous mode) for backward
#              compatibility of the driver behavior.
#

# These directives are common to all drivers that support ups.conf:
#
#  driver: REQUIRED.  Specify the program to run to talk to this UPS.
#          apcsmart, bestups, and sec are some examples.
#
#    port: REQUIRED.  The serial port where your UPS is connecte#    desc: optional, to keep a note of the UPS purpose, location, etc.
#
#  nolock: optional, and not recommended for use in this file.
#
#          If you put nolock in here, the driver will not lock the
#          serial port every time it starts.  This may allow other
#          processes to seize the port if you start more than one by
#          mistake.
#
#          This is only intended to be used on systems where locking
#          absolutely must be disabled for the software to work.
#
# ignorelb: OPTIONAL. Ignore low battery condition reported by device,
#           and evaluate remaining battery charge or runtime instead.
#           See man page for details.
#
# usb_set_altinterface(=num): OPTIONAL. Require that NUT calls this method
#           to set the interface, even if 0 (default). Some devices require
#           the call to initialize; others however can get stuck due to it -
#           so it is not called by default. Yet others can be composite
#           devices which use a non-zero interface to represent the UPS.
#
# default.<variable>: OPTIONAL. Set a default value for <variable> which is
#           used in case the UPS doesn't provide a value, but which will be
#           overwritten if a value is available from the UPS, e.g.:
#               default.input.voltage.nominal = 230
#           will report the nominal input voltage to be 230, unless the UPS
#           eventually tells us differently.
#
# override.<variable>: OPTIONAL. Set a value for <value> that overrides
#           (for NUT) any value that may be read from the UPS.
#           Used for overriding values from the UPS that are clearly wrong
#           (e.g. some devices report wrong values for battery voltage):
#               override.battery.voltage.nominal = 12
#           Use with caution!  This will only change the appearance of the
#           variable to the outside world (and NUT calculations), internally
#           in the UPS the original value is used.
#
# Anything else is passed through to the hardware-specific part of
# the driver.
#
# Examples
# --------
#
# A simple example for a UPS called "powerpal" that uses the blazer_ser
# driver on /dev/ttyS0 is:
#
# [powerpal]
#   driver = blazer_ser
#   port = /dev/ttyS0
#   desc = "Web server"
#
# If your UPS driver requires additional settings, you can specify them
# here.  For example, if it supports a setting of "1234" for the
# variable "cable", it would look like this:
#
# [myups]
#   driver = mydriver
#   port = /dev/ttyS1
#   cable = 1234
#   desc = "Something descriptive"
#
# To find out if your driver supports any extra settings, start it with
# the -h option and/or read the driver's documentation.
[ups]
        driver = "usbhid-ups"
        port = "auto"
        desc = "ups"
        pollinterval = 10
        override.battery.charge.low = 35
        override.battery.runtime.low = 600

# Network UPS Tools: example upsd configuration file
#
# This file contains access control data, you should keep it secure.
#
# It should only be readable by the user that upsd becomes.  See the FAQ.
#
# Each entry below provides usage and default value.
#
# For more information, refer to upsd.conf manual page.

# =======================================================================
# MAXAGE <seconds>
# MAXAGE 15
#
# This defaults to 15 seconds.  After a UPS driver has stopped updating
# the data for this many seconds, upsd marks it stale and stops making
# that information available to clients.  After all, the only thing worse
# than no data is bad data.
#
# You should only use this if your driver has difficulties keeping
# the data fresh within the normal 15 second interval.  Watch the syslog
# for notifications from upsd about staleness.

# =======================================================================
# TRACKINGDELAY <seconds>
# TRACKINGDELAY 3600
#
# This defaults to 1 hour. When instant commands and variables setting status
# tracking is enabled, status execution information are kept during this
# amount of time, and then cleaned up.

# =======================================================================
# ALLOW_NO_DEVICE <Boolean>
# ALLOW_NO_DEVICE true
#
# Normally upsd requires that at least one device section is defined in ups.conf
# when the daemon starts, to serve its data.  For automatically managed services
# it may be preferred to have upsd always running, and reload the configuration
# when power devices become defined.
#
# Boolean values 'true', 'yes', 'on' and '1' mean that the server would not
# refuse to start with zero device sections found in ups.conf.
#
# Boolean values 'false', 'no', 'off' and '0' mean that the server should refuse
# to start if zero device sections were found in ups.conf. This is the default.

# =======================================================================
# STATEPATH <path>
# STATEPATH /var/run/nut
#
# Tell upsd to look for the driver state sockets in 'path' rather
# than the default that was compiled into the program.

# =======================================================================
# LISTEN <IP address or name> [<port>]
# LISTEN 127.0.0.1 3493
# LISTEN ::1 3493
# LISTEN myhostname 83493
# LISTEN myhostname.mydomain
#
# This defaults to the localhost listening addresses and port 3493.
# In case of IP v4 or v6 disabled kernel, only the available one will be used.
#
# You may specify each interface IP address or name that you want upsd to
# listen on for connections, optionally with a port number.
#
# You may need this if you have multiple interfaces on your machine and
# you don't want upsd to listen to all interfaces (for instance on a
# firewall, you may not want to listen to the external interface).
#
# This will only be read at startup of upsd.  If you make changes here,
# you'll need to restart upsd, reload will have no effect.

# =======================================================================
# MAXCONN <connections>
# MAXCONN 1024
#
# This defaults to maximum number allowed on your system.  Each UPS, each
# LISTEN address and each client count as one connection.  If the server
# runs out of connections, it will no longer accept new incoming client
# connections.  Only set this if you know exactly what you're doing.

# =======================================================================
# CERTFILE <certificate file>
# CERTFILE /usr/local/ups/etc/upsd.pem
#
# When compiled with SSL support with OpenSSL backend,
# you can enter the certificate file here.
# The certificates must be in PEM format and must be sorted starting with
# the subject's certificate (server certificate), followed by intermediate
# CA certificates (if applicable_ and the highest level (root) CA. It should
# end with the server key. See 'docs/security.txt' or the Security chapter of
# NUT user manual for more information on the SSL support in NUT.
#
# See 'docs/security.txt' or the Security chapter of NUT user manual
# for more information on the SSL support in NUT.

# =======================================================================
# CERTPATH <certificate file or directory>
# CERTPATH /usr/local/ups/etc/cert/upsd
#
# When compiled with SSL support with NSS backend,
# you can enter the certificate path here.
# Certificates are stored in a dedicated database (split into 3 files).
# Specify the path of the database directory.
#
# See 'docs/security.txt' or the Security chapter of NUT user manual
# for more information on the SSL support in NUT.

# =======================================================================
# CERTIDENT <certificate name> <database password>
# CERTIDENT "my nut server" "MyPasSw0rD"
#
# When compiled with SSL support with NSS backend,
# you can specify the certificate name to retrieve from database to
# authenticate itself and the password
# required to access certificate related private key.
#
# See 'docs/security.txt' or the Security chapter of NUT user manual
# for more information on the SSL support in NUT.

# =======================================================================
# CERTREQUEST <certificate request level>
# CERTREQUEST REQUIRE
#
# When compiled with SSL support with NSS backend and client certificate
# validation (disabled by default, see 'docs/security.txt'),
# you can specify if upsd requests or requires client's' certificates.
# Possible values are :
#  - 0 to not request to clients to provide any certificate
#  - 1 to require to all clients a certificate
#  - 2 to require to all clients a valid certificate
#
# See 'docs/security.txt' or the Security chapter of NUT user manual
# for more information on the SSL support in NUT.

# =======================================================================
# DISABLE_WEAK_SSL <Boolean>
# DISABLE_WEAK_SSL true
#
# Tell upsd to disable older/weak SSL/TLS protocols and ciphers.
#
# With relatively recent versions of OpenSSL or NSS it will be restricted
# to TLSv1.2 or better.
#
# Unless you have really ancient clients, you probably want to enable this.
# Currently disabled by default to ensure compatibility with existing setups.

# =======================================================================
# DEBUG_MIN <Integer>
# DEBUG_MIN 2
#.
# Optionally specify a minimum debug level for `upsd` data daemon, e.g. for
# troubleshooting a deployment, without impacting foreground or background
# running mode directly, and without need to edit init-scripts or service
# unit definitions. Note that command-line option `-D` can only increase
# this verbosity level.
#
# NOTE: if the running daemon receives a `reload` command, presence of the
# `DEBUG_MIN NUMBER` value in the configuration file can be used to tune
# debugging verbosity in the running service daemon (it is recommended to
# comment it away or set the minimum to explicit zero when done, to avoid
# huge journals and I/O system abuse). Keep in mind that for this run-time
# tuning, the `DEBUG_MIN` value *present* in *reloaded* configuration files
# is applied instantly and overrides any previously set value, from file
# or CLI options, regardless of older logging level being higher or lower
# than the newly found number; a missing (or commented away) value however
# does not change the previously active logging verbosity.
LISTEN 0.0.0.0 3493
LISTEN 192.168.99.33 3493
LISTEN 192.168.99.58 3493

# Network UPS Tools: Example upsd.users
#
# This file sets the permissions for upsd - the UPS network daemon.
# Users are defined here, are given passwords, and their privileges are
# controlled here too.  Since this file will contain passwords, keep it
# secure, with only enough permissions for upsd to read it.

# --------------------------------------------------------------------------

# Each user gets a section.  To start a section, put the username in
# brackets on a line by itself.  To set something for that user, specify
# it under that section heading.  The username is case-sensitive, so
# admin and AdMiN are two different users.
#
# Possible settings:
#
# password: The user's password.  This is case-sensitive.
#
# --------------------------------------------------------------------------
#
# actions: Let the user do certain things with upsd.
#
# Valid actions are:
#
# SET   - change the value of certain variables in the UPS
# FSD   - set the "forced shutdown" flag in the UPS
#
# --------------------------------------------------------------------------
#
# instcmds: Let the user initiate specific instant commands.  Use "ALL"
# to grant all commands automatically.  There are many possible
# commands, so use 'upscmd -l' to see what your hardware supports.  Here
# are a few examples:
#
# test.panel.start      - Start a front panel test
# test.battery.start    - Start battery test
# test.battery.stop     - Stop battery test
# calibrate.start       - Start calibration
# calibrate.stop        - Stop calibration
#
# --------------------------------------------------------------------------
#
# Example:
#
#	[admin]
#		password = mypass
#		actions = SET
#		instcmds = ALL
#

#
# --- Configuring for a user who can execute tests only
#
#	[testuser]
#		password  = pass
#		instcmds  = test.battery.start
#		instcmds  = test.battery.stop

#
# --- Configuring for upsmon
#
# To add a user for your upsmon, use this example:
#
#   [upsmon]
#       password  = pass
#       upsmon primary
# or
#       upsmon secondary
#
# The matching MONITOR line in your upsmon.conf would look like this:
#
# MONITOR myups@localhost 1 upsmon pass primary	(or secondary)
#
# See comments in the upsmon.conf(.sample) file for details about this
# keyword and the difference of NUT secondary and primary systems.
[usv]
       password = xxxxx
       actions = SET
       instcmds = ALL
       upsmon master

wendy2702

schrieb am

#36

@David-G. Mega, Vielen Dank!

W wendy2702

@David-G. Mega, Vielen Dank!
D Online
D Online
David G.

schrieb am zuletzt editiert von

#37

@wendy2702

Bei deiner USV musst du natürlich recherchieren, welchen Treiber man angeben muss.
Zeigt eure Lovelace-Visualisierung klick
(Auch ideal um sich Anregungen zu holen)

Meine Tabellen für eure Visualisierung klick
W 1 Antwort Letzte Antwort

0
D David G.

@wendy2702

Bei deiner USV musst du natürlich recherchieren, welchen Treiber man angeben muss.
W Online
W Online
wendy2702

schrieb am zuletzt editiert von

#38

@David-G. Ja.

Das weiß ich noch. Hatte das vor x Jahren mal laufen aber damals nicht unter Proxmox
Bitte keine Fragen per PN, die gehören ins Forum!

Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
1 Antwort Letzte Antwort

0
W Online
W Online
wendy2702

schrieb am zuletzt editiert von

#39

@david-g. Danke nochmal für deine CONF Daten. USV läuft jetzt am ersten Server. Jetzt noch was mit Blockly häkeln damit alles irgenwann runterfährt.
Bitte keine Fragen per PN, die gehören ins Forum!

Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
1 Antwort Letzte Antwort

0
N Offline
N Offline
Negalein
Global Moderator
schrieb am zuletzt editiert von Negalein

#40
muss mich auch kurz einklinken.

ChatGPT schlägt mir folgendes vor. Passt da vorallem das wegen Proxmox?
Du:
2 usv in 2 räumen

raum 1:
--> Proxmox mit 8 LXC
--> Synology DS718+ --> USV (USV-Server)

raum 2:
--> Proxmox mit 8 LXC
--> Proxmox mit 6 LXC
--> Windows 10 PC mit funktionierendem WinNUT
--> Synology DS918+ --> USV (USV-Server)

bei stromausfall soll alles sicher heruntergefahren werden.
zuerst LXCs, dan Proxmox Host, dann Windows 10 PC.
Jede USV regelt nur ihren Raum.

ChatGPT:
Super – sauberes Setup 👍
Ziel: Jeder Raum fährt sich bei Stromausfall autonom & geordnet herunter.

Shutdown-Reihenfolge je Raum:

LXC Container

Proxmox Host

Windows 10 PC (nur Raum 2)

Und:
➡️ Jede USV steuert nur ihren Raum
➡️ Kein Raum-übergreifendes Chaos
➡️ Kein hartes Power-Off

🔌 Architektur (empfohlen)
Du hast bereits die perfekte Basis:

Raum USV hängt an Rolle
Raum 1 DS718+ NUT Server
Raum 2 DS918+ NUT Server
➡️ Synology spielt jeweils Master (NUT Server)
➡️ Alle anderen Geräte = NUT Clients

🧠 Grundprinzip
Synology erkennt Stromausfall → startet Timer → sendet Shutdown an Clients → Clients fahren sauber runter → Host fährt zuletzt runter

Wichtig:
👉 Proxmox darf nicht sofort runterfahren
→ zuerst müssen die LXCs stoppen

Das lösen wir mit einem Shutdown Script auf Proxmox

🏠 Raum 1 Setup

Synology DS718+ (USV Master)
DSM:

Systemsteuerung → Hardware & Energie → USV
Aktivieren:

✅ USV-Unterstützung aktivieren
✅ Netzwerk-USV-Server aktivieren
IP erlauben:

Proxmox_Raum1_IP
Optional:

👉 „Nach X Minuten herunterfahren“ = z.B. 5 min

Proxmox Raum 1 = NUT Client
Paket installieren
apt install nut-client
/etc/nut/nut.conf
MODE=netclient
/etc/nut/upsmon.conf
MONITOR ups@SYNOLOGY_IP 1 monuser secret slave
SHUTDOWNCMD "/usr/local/sbin/proxmox-ups-shutdown.sh"
POWERDOWNFLAG /etc/killpower
/etc/nut/upsd.users
[monuser]
password = secret
upsmon slave
🧨 Proxmox Shutdown Script (wichtig!)
nano /usr/local/sbin/proxmox-ups-shutdown.sh
#!/bin/bash

logger "UPS: Shutdown gestartet - stoppe LXCs"

LXCs sauber stoppen

pct list | awk 'NR>1 {print $1}' | while read id; do
pct shutdown $id &
done

wait

logger "UPS: LXCs gestoppt - fahre Host runter"

sleep 30

shutdown -h now
chmod +x /usr/local/sbin/proxmox-ups-shutdown.sh
🏠 Raum 2 Setup
Hier gleich – aber mit Windows Integration.

DS918+ = USV Master
Wie oben, aber erlaubte IPs:

Proxmox1_Raum2
Proxmox2_Raum2
Windows10_IP
2. Beide Proxmox = gleiche Client Config wie Raum 1
Nur:

SYNOLOGY_IP = DS918+
🪟 Windows 10 PC (WinNUT vorhanden 👍)
In WinNUT:

UPS Mode:

Remote UPS (slave)
UPS IP:

DS918+ IP
Shutdown Delay:

👉 z.B. 180 Sekunden

Damit:

➡️ LXCs fahren zuerst runter
➡️ Proxmox danach
➡️ Windows zuletzt

🧭 Shutdown Reihenfolge ergibt sich automatisch
Synology meldet:

👉 OB LB (On Battery)

Dann:

Proxmox Script stoppt LXCs

Proxmox Host fährt runter

Windows fährt später runter (Delay)

⚡ Wichtig: Synology selbst
DSM Einstellung:

👉 „USV herunterfahren wenn alle Clients offline“

Damit:

➡️ NAS bleibt solange online bis alles safe ist
➡️ Dann erst final shutdown

🔁 Test unbedingt machen!
Test:

USV vom Netz trennen
Check:

✔ LXCs stoppen
✔ Hosts fahren runter
✔ Windows fährt runter
✔ NAS zuletzt

🧱 Ergebnis
Beide Räume sind:

✅ Autonom
✅ Reihenfolge sauber
✅ Kein Datenverlust
✅ Kein Cross-Room Chaos
° Node.js & System Update ---> sudo apt update, iob stop, sudo apt full-upgrade
° Node.js Fixer ---> iob nodejs-update
° Fixer ---> iob fix
1 Antwort Letzte Antwort

0
P Offline
P Offline
peterfido

schrieb am zuletzt editiert von

#41

ChatGPT sagt dauernd "Super" "sauber", etc.

Meine einfache Regel: Die großen Stromfresser zuerst. Also NAS mit vielen Festplatten, Windows PC und so halt. Proxmox beendet alles automatisch in der umgekehrten Reihenfolge des Startens. Da braucht man nicht manuell eingreifen.

Windows macht gelegentlich Ärger, wenn da was nicht gespeichert wurde. Da muss der Befehl zum Herunterfahren Forcieren.
Gruß

Peterfido

Proxmox auf Intel NUC12WSHi5
ioBroker: Debian (VM)
CCU: Debmatic (VM)
Influx: Debian (VM)
Grafana: Debian (VM)
eBus: Debian (VM)
Zigbee: Debian (VM) mit zigbee2mqtt
N 1 Antwort Letzte Antwort

0
D Online
D Online
David G.

schrieb am zuletzt editiert von David G.

#42

Hab dein ChatGPT Kram nur ganz grob im Ansatz überflogen (Hier im Forum lese ich nur, was Menschen schreiben, keine 10 Seiten aus ChatGPT).

Ich würde sagen, es ist Geschmackssache. Außer beide Standorte wären an verschiedenen Sicherungen im Haus.
Zeigt eure Lovelace-Visualisierung klick
(Auch ideal um sich Anregungen zu holen)

Meine Tabellen für eure Visualisierung klick
N 1 Antwort Letzte Antwort

0
P peterfido

ChatGPT sagt dauernd "Super" "sauber", etc.

Meine einfache Regel: Die großen Stromfresser zuerst. Also NAS mit vielen Festplatten, Windows PC und so halt. Proxmox beendet alles automatisch in der umgekehrten Reihenfolge des Startens. Da braucht man nicht manuell eingreifen.

Windows macht gelegentlich Ärger, wenn da was nicht gespeichert wurde. Da muss der Befehl zum Herunterfahren Forcieren.
N Offline
N Offline
Negalein
Global Moderator
schrieb zuletzt editiert von

#43
@peterfido sagte in [gelöst] USV an Proxmox in LXC durchreichen:

Die großen Stromfresser zuerst. Also NAS mit vielen Festplatten, Windows PC und so halt. Proxmox beendet alles automatisch in der umgekehrten Reihenfolge des Startens

Synology muss bis zum schluß warten, da Nut-Server.

Benötigt man auf Proxmox das Shutdown-Script? Oder geht das auch anders?
```
#!/bin/bash

logger "UPS RAUM2-PVE1: Batterie <50% - stoppe LXCs"

pct list | awk 'NR>1 {print $1}' | while read id; do
    pct shutdown $id &
done

wait

logger "UPS RAUM2-PVE1: LXCs gestoppt - warte 120s"

sleep 120

shutdown -h now
```
° Node.js & System Update ---> sudo apt update, iob stop, sudo apt full-upgrade
° Node.js Fixer ---> iob nodejs-update
° Fixer ---> iob fix
1 Antwort Letzte Antwort

0
D David G.

Hab dein ChatGPT Kram nur ganz grob im Ansatz überflogen (Hier im Forum lese ich nur, was Menschen schreiben, keine 10 Seiten aus ChatGPT).

Ich würde sagen, es ist Geschmackssache. Außer beide Standorte wären an verschiedenen Sicherungen im Haus.
N Offline
N Offline
Negalein
Global Moderator
schrieb zuletzt editiert von

#44

@David-G. sagte in [gelöst] USV an Proxmox in LXC durchreichen:

Außer beide Standorte wären an verschiedenen Sicherungen im Haus.

Ja, sind sie
° Node.js & System Update ---> sudo apt update, iob stop, sudo apt full-upgrade
° Node.js Fixer ---> iob nodejs-update
° Fixer ---> iob fix
D 1 Antwort Letzte Antwort

0
N Negalein

@David-G. sagte in [gelöst] USV an Proxmox in LXC durchreichen:

Außer beide Standorte wären an verschiedenen Sicherungen im Haus.

Ja, sind sie
D Online
D Online
David G.

schrieb zuletzt editiert von

#45

@Negalein

Dann sollte es besser ganz getrennt voneinander laufen. Wäre ja doof, wenn bei A alles runter fährt wenn nur bei B die Sicherung fliegt.
Zeigt eure Lovelace-Visualisierung klick
(Auch ideal um sich Anregungen zu holen)

Meine Tabellen für eure Visualisierung klick
1 Antwort Letzte Antwort

0

Anmelden zum Antworten

Support us

634

Online

32.7k

Benutzer

82.4k

Themen

1.3m

Beiträge