Linux und WAN Addon
Re: Linux und WAN Addon
Das swaudit funktioniert wohl nicht im WAN-Modus ...
Re: Linux und WAN Addon
Hallo,
leider funktioniert das mit dem akutllen opsi-client-agent immer noch nicht zufriedenstellend unter Linux. Ist das in nächster Zeit Besserung zu erwarten?
Viele Grüße,
Stefan
leider funktioniert das mit dem akutllen opsi-client-agent immer noch nicht zufriedenstellend unter Linux. Ist das in nächster Zeit Besserung zu erwarten?
Viele Grüße,
Stefan
Re: Linux und WAN Addon
Hallo Stefan,
ich kann das nicht reproduzieren.
Habe eben mal getestet mit xUbuntu 20.04 und swaudit 4.2.0.0-1 losgetreten über timer-event -> reboot.
Wie äußert sich denn der Fehler und unter welchen Umständen tritt er auf?
Gruß
Nils
ich kann das nicht reproduzieren.
Habe eben mal getestet mit xUbuntu 20.04 und swaudit 4.2.0.0-1 losgetreten über timer-event -> reboot.
Wie äußert sich denn der Fehler und unter welchen Umständen tritt er auf?
Gruß
Nils
Re: Linux und WAN Addon
Hallo Nils,
also mir macht der WAN-Client leider ganz normalen GUI-Startup, d.h. er kontaktiert den Configserver und führt anstehende Aktionen durch. Wenn er vorher etwas gecached hat, werden die Aktionen aber im WAN-Modus abgearbeitet und erst beim nächsten mal kommt wieder ein traditionelles GUI-Startup-Event.
Viele Grüße,
Stefan
also mir macht der WAN-Client leider ganz normalen GUI-Startup, d.h. er kontaktiert den Configserver und führt anstehende Aktionen durch. Wenn er vorher etwas gecached hat, werden die Aktionen aber im WAN-Modus abgearbeitet und erst beim nächsten mal kommt wieder ein traditionelles GUI-Startup-Event.
Viele Grüße,
Stefan
Re: Linux und WAN Addon
Dann ist vermutlich die Event-Konfiguration nicht ganz richtig. Bei meinem linux WAN-Testclient habe ich das so eingerichtet:
Entweder "gui_startup{cache_ready}" oder "opsiclientd_start{cache_ready}" muss aktiv sein.
(analog zu windows)
Entweder "gui_startup{cache_ready}" oder "opsiclientd_start{cache_ready}" muss aktiv sein.
Re: Linux und WAN Addon
So siehts bei mir auf dem Cliet aus:
Code: Alles auswählen
# grep event_ -A4 /etc/opsi-client-agent/opsiclientd.conf
[event_default]
; === Event configuration
# Type of the event (string)
type = template
# Time in seconds after which a timer / custom event is triggered for the first time after event activation (int, 0 = disabled).
--
event_notifier_command = %opsiclientd_notifier.command% -s notifier/event.ini
# The desktop on which the event notifier will be shown on (all/current/default/winlogon)
event_notifier_desktop = all
# Block login while event is been executed (bool)
block_login = false
# Lock workstation on event occurrence (bool)
lock_workstation = false
--
post_event_command =
; === Sync/cache settings
# Sync configuration from local config cache to server (bool)
sync_config_to_server = false
--
[event_opsiclientd_start]
super = default
type = daemon startup
active = true
activation_delay = 10
--
[event_opsiclientd_start{cache_ready}]
use_cached_config = true
use_cached_products = true
[event_gui_startup]
super = default
type = gui startup
active = false
block_login = true
--
[event_gui_startup{user_logged_in}]
active = false
shutdown_warning_time = 3600
block_login = false
[event_gui_startup{cache_ready}]
active = false
use_cached_config = true
use_cached_products = true
action_user_cancelable = 3
--
[event_gui_startup{installation_pending}]
active = false
[event_on_demand]
super = default
type = custom
[event_on_demand{user_logged_in}]
shutdown_warning_time = 3600
[event_software_on_demand]
super = default
type = sw on demand
shutdown_warning_time = 3600
[event_sync]
super = default
type = template
process_actions = false
event_notifier_command =
sync_config_to_server = true
sync_config_from_server = true
cache_products = true
cache_dynamic_bandwidth = true
--
[event_timer]
super = sync
type = timer
active = true
interval = 3600
--
[event_net_connection]
super = sync
type = custom
active = true
[event_sync_completed]
super = default
type = sync completed
event_notifier_command =
process_actions = false
get_config_from_service = false
write_log_to_service = false
[event_sync_completed{cache_ready_user_logged_in}]
reboot = true
shutdown_user_cancelable = 10
shutdown_warning_time = 28000
[event_sync_completed{cache_ready}]
reboot = true
[event_on_shutdown]
super = default
type = custom
active = false
max_repetitions = 0
--
[event_on_shutdown{installation_pending}]
active = false
[event_silent_install]
super = default
type = custom
event_notifier_command =
process_shutdown_requests = false
action_processor_command = %action_processor.command% -productlist %action_processor_productIds% -silent
action_processor_desktop = winlogon
action_processor_timeout = 300
--
[event_timer_silentinstall]
super = silent_install
type = timer
active = false
interval = 21600
--
[event_user_login]
action_processor_command = %action_processor.command% /sessionid service_session /loginscripts /silent
active = false
Re: Linux und WAN Addon
Die Event-Konfiguration sieht bei mir im Prinzip genauso aus.
Eventuell reden wir aneinander vorbei.
Im WAN-Modus soll beim booten, wenn etwas gecached ist, direkt aus diesem Cache installiert werden und nicht vom depot. Erst beim nächsten timer-Event wird die Konfiguration gesynct (also vom client die info, was installiert wurde an den server und vom server ggfs neue Konfigurationen an den client.). Das net_connection Event, was es für windows gibt, tut unter linux und macos nichts.
Eventuell reden wir aneinander vorbei.
Das klingt für mich nach dem korrekten Verhalten außer, dass ich mir nicht sicher bin, was mit traditionellem GUI-Startup-Event gemeint ist.also mir macht der WAN-Client leider ganz normalen GUI-Startup, d.h. er kontaktiert den Configserver und führt anstehende Aktionen durch. Wenn er vorher etwas gecached hat, werden die Aktionen aber im WAN-Modus abgearbeitet und erst beim nächsten mal kommt wieder ein traditionelles GUI-Startup-Event.
Im WAN-Modus soll beim booten, wenn etwas gecached ist, direkt aus diesem Cache installiert werden und nicht vom depot. Erst beim nächsten timer-Event wird die Konfiguration gesynct (also vom client die info, was installiert wurde an den server und vom server ggfs neue Konfigurationen an den client.). Das net_connection Event, was es für windows gibt, tut unter linux und macos nichts.
Re: Linux und WAN Addon
Situation:
Der WAN-Client startet und keine Produkte sind gecached. Ggf sind Aktionen auf dem Opsi-Server gesetzt.
Erwartetes Verhalten:
Der Client startet ohne daß man etwas von opsi merkt und man kann sich unbehelligt anmelden. Im Hintergrund werden gff. aktivierte Produkte gecached.
Beobachtetes Verhalten:
Der opsi-client-agent startet sichtbar, kontaktiert den Server und führt Aktionen direkt aus und meldet das Ergebnis auch direkt zurück.
Der WAN-Client startet und keine Produkte sind gecached. Ggf sind Aktionen auf dem Opsi-Server gesetzt.
Erwartetes Verhalten:
Der Client startet ohne daß man etwas von opsi merkt und man kann sich unbehelligt anmelden. Im Hintergrund werden gff. aktivierte Produkte gecached.
Beobachtetes Verhalten:
Der opsi-client-agent startet sichtbar, kontaktiert den Server und führt Aktionen direkt aus und meldet das Ergebnis auch direkt zurück.
Re: Linux und WAN Addon
Ah ja, um das zu unterbinden müssen diese ConfigStates gesetzt sein:
opsiclientd.event_opsiclientd_start.active False
opsiclientd.event_opsiclientd_start{user_logged_in}.active False
Aktuell werden diese ConfigStates noch nicht durch das "WAN configuration" Häkchen im configed gesetzt.
Wir werden das intern diskutieren.
opsiclientd.event_opsiclientd_start.active False
opsiclientd.event_opsiclientd_start{user_logged_in}.active False
Aktuell werden diese ConfigStates noch nicht durch das "WAN configuration" Häkchen im configed gesetzt.
Wir werden das intern diskutieren.
Re: Linux und WAN Addon
Ich nehme an das ist eine undokumentierte Spezialität für den Linux-Client? Unter Windows funktionierts nach der Ausführung von opsi-wan-config-on