Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

dienst automatisch deaktivieren nach upgrade?

2 views
Skip to first unread message

Kay Martinen

unread,
Nov 21, 2023, 11:50:03 AM11/21/23
to
Hallo

Gibt es eine stelle an der man einen bestimmten dienst (erneut)
deaktivieren kann falls der nach einem 'apt upgrade' neu gestartet wurde?

Ich denke dabei z.b. an teamviewer den ich nur selten mal für "Admin
wieder willen" Jobs in der Familie nutze.

Und ich habe es mehrfach erlebt das der nach einem update seines
(dritt)pakets auf ein mal wieder läuft. Auch wenn ich ihn vorher per
syystemctl als disabled setzte. Das will ich verhindern weil das modul
m.W. auch für Remote-zugang auf MEINEN Rechner zuständig wäre. Und der
soll dauerhaft aus sein und bleiben = Stop-Verriegelt!

Es scheint das der seinen hintergrunddienst nach dem aktualisieren
einfach wieder auf enabled setzt und startet. Den am updaten zu hindern
will ich nicht weil es sonst eine evtl. nötige Sitzung gefährden könnte
(Sicherheit).

Was ich also will ist entweder das neustarten verhindern oder zuletzt
automatisch zu schauen ob er evtl. aktiv ist und ihn wieder zu
deaktivieren und zu stoppen.

Gibt es da irgendwo einen passenden Hook/script o.a. im apt Ablauf wo
man ein systemctl disable/stop teamviewer.service einfügen könnte?

Bye/
/Kay

--
"Kann ein Wurstbrot die Welt retten?" :-)

Marco Moock

unread,
Nov 21, 2023, 12:02:39 PM11/21/23
to
Am 21.11.2023 um 17:46:04 Uhr schrieb Kay Martinen:

> Was ich also will ist entweder das neustarten verhindern oder zuletzt
> automatisch zu schauen ob er evtl. aktiv ist und ihn wieder zu
> deaktivieren und zu stoppen.
>
> Gibt es da irgendwo einen passenden Hook/script o.a. im apt Ablauf wo
> man ein systemctl disable/stop teamviewer.service einfügen könnte?

Was spricht gegen Maskieren und dann bei Bedarf entmaskieren?

Frank B

unread,
Nov 21, 2023, 12:54:21 PM11/21/23
to
Am 21.11.23 um 18:02 schrieb Marco Moock:
Oder immer auf Verdacht beim systemstart / logon
systemctl disable teamviewer --now
aufrufen

Marcel Mueller

unread,
Nov 21, 2023, 1:32:59 PM11/21/23
to
Am 21.11.23 um 17:46 schrieb Kay Martinen:
> Gibt es eine stelle an der man einen bestimmten dienst (erneut)
> deaktivieren kann falls der nach einem 'apt upgrade' neu gestartet wurde?

Systemd? Dann kannst du mit Overrides arbeiten und einzelne Properties
der Units überschreiben.


> Und ich habe es mehrfach erlebt das der nach einem update seines
> (dritt)pakets auf ein mal wieder läuft.

Ja, die Installer stellen normalerweise den Zielzustand so gut wie
möglich wieder her.


> Gibt es da irgendwo einen passenden Hook/script o.a. im apt Ablauf wo
> man ein systemctl disable/stop teamviewer.service einfügen könnte?

Da bin ich überfragt.


Marcel

Jan Novak

unread,
Nov 22, 2023, 12:55:02 AM11/22/23
to
Am 21.11.23 um 17:46 schrieb Kay Martinen:
> Hallo
>
> Gibt es eine stelle an der man einen bestimmten dienst (erneut)
> deaktivieren kann falls der nach einem 'apt upgrade' neu gestartet wurde?
>
> Ich denke dabei z.b. an teamviewer den ich nur selten mal für "Admin
> wieder willen" Jobs in der Familie nutze.

Gleiches bei mir. Ich habe ihn installiert aber brauche ihn nur sehr
selten. Nach jeden Update wird er wieder (auto-)gestartet.

Jan


Diedrich Ehlerding

unread,
Nov 22, 2023, 3:14:21 AM11/22/23
to
Kay Martinen meinte:

> Gibt es eine stelle an der man einen bestimmten dienst (erneut)
> deaktivieren kann falls der nach einem 'apt upgrade' neu gestartet
> wurde?

sudo systemctl disable <xxxx>.service (evtl. "... disable --now ...",
wenn du ihn auch in der laufenden Sitzung schon loswerden willst)
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

Kay Martinen

unread,
Nov 22, 2023, 7:40:03 AM11/22/23
to
Am 22.11.23 um 09:05 schrieb Diedrich Ehlerding:
> Kay Martinen meinte:
>
>> Gibt es eine stelle an der man einen bestimmten dienst (erneut)
>> deaktivieren kann falls der nach einem 'apt upgrade' neu gestartet
>> wurde?
>
> sudo systemctl disable <xxxx>.service (evtl. "... disable --now ...",
> wenn du ihn auch in der laufenden Sitzung schon loswerden willst)

Ja ich weiß. Aber das hilft nur wenn man es danach händisch macht. Denn
nach einem upgrade läuft der meist dennoch wieder. Der ignoriert also
das disable.

Und mit 'mask' habe ich noch keine Erfahrungen wie man das anwendet. Und
ob es wirklich "härter" abschaltet. Was ich eingedenk obigem annehmen
muß das es auch übersteuert wird.

Peter Heitzer

unread,
Nov 22, 2023, 8:17:39 AM11/22/23
to
Kay Martinen <use...@martinen.de> wrote:
>Hallo

>Gibt es eine stelle an der man einen bestimmten dienst (erneut)
>deaktivieren kann falls der nach einem 'apt upgrade' neu gestartet wurde?
Du könntest regelmässig in /var/log/apt/history.log mittels Skript
nachschauen, ob apt upgrade gelaufen ist und dann den Status des
Dienstes überprüfen und ggv. den Dienst stoppen und disablen.

--
Dipl.-Inform(FH) Peter Heitzer, peter....@rz.uni-regensburg.de

Christian Garbs

unread,
Nov 22, 2023, 9:04:32 AM11/22/23
to
Mahlzeit!

Kay Martinen <use...@martinen.de> wrote:

> Gibt es eine stelle an der man einen bestimmten dienst (erneut)
> deaktivieren kann falls der nach einem 'apt upgrade' neu gestartet wurde?
>
> Ich denke dabei z.b. an teamviewer den ich nur selten mal für "Admin
> wieder willen" Jobs in der Familie nutze.
>
> Und ich habe es mehrfach erlebt das der nach einem update seines
> (dritt)pakets auf ein mal wieder läuft. Auch wenn ich ihn vorher per
> syystemctl als disabled setzte. Das will ich verhindern weil das modul
> m.W. auch für Remote-zugang auf MEINEN Rechner zuständig wäre. Und der
> soll dauerhaft aus sein und bleiben = Stop-Verriegelt!
>
> Es scheint das der seinen hintergrunddienst nach dem aktualisieren
> einfach wieder auf enabled setzt und startet. Den am updaten zu hindern
> will ich nicht weil es sonst eine evtl. nötige Sitzung gefährden könnte
> (Sicherheit).

Wird er denn nur einmalig neu gestartet (systemctl start) oder
tatsächlich wieder enabled?

Vielleicht ist das ein Bug in dem Paket?


Ich kenne die offiziellen Vorgaben nicht, meine mich aber grob an
folgendes erinnern zu können:

1. wenn ein Dienst installiert wird, wird er auch gleich gestartet,
sofern möglich (sonst hätte man ihn ja nicht installiert)

2. wenn der Admin etwas umkonfiguriert, dann wird das auch bei Updates
beachtet

Hier würde sich dann 1. mit 2. beißen und ich bin mir unsicher, ob es
eine entsprechende Regel gibt wie "2. hat Vorrang vor 1.".

Müsste man mal irgendwo nachgucken, um dann sagen zu können "ja, das
soll so" oder "das ist ein Bug".


Ansonsten wirklich maskieren, aber das kann es ja eigentlich nicht
sein (oder es ist gar der offizielle Debian-Weg für sowas).

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Von meinem iPhone gesendet

Arno Welzel

unread,
Nov 22, 2023, 9:28:10 AM11/22/23
to
Kay Martinen, 2023-11-21 17:46:

[...]
> Was ich also will ist entweder das neustarten verhindern oder zuletzt
> automatisch zu schauen ob er evtl. aktiv ist und ihn wieder zu
> deaktivieren und zu stoppen.
>
> Gibt es da irgendwo einen passenden Hook/script o.a. im apt Ablauf wo
> man ein systemctl disable/stop teamviewer.service einfügen könnte?

Evtl. mit Triggern:

<https://wiki.debian.org/DpkgTriggers>

Siehe dazu auch hier:

<https://stackoverflow.com/questions/15276535/dpkg-how-to-use-trigger/15276537>

--
Arno Welzel
https://arnowelzel.de

Diedrich Ehlerding

unread,
Nov 22, 2023, 1:37:28 PM11/22/23
to
Kay Martinen meinte:

>>> Gibt es eine stelle an der man einen bestimmten dienst (erneut)
>>> deaktivieren kann falls der nach einem 'apt upgrade' neu gestartet
>>> wurde?
>>
>> sudo systemctl disable <xxxx>.service (evtl. "... disable --now ...",
>> wenn du ihn auch in der laufenden Sitzung schon loswerden willst)
>
> Ja ich weiß. Aber das hilft nur wenn man es danach händisch macht.
> Denn nach einem upgrade läuft der meist dennoch wieder. Der ignoriert
> also das disable.

Ja, du suchtest ja auch nach "erneut deaktivieren" - das hatte ich so
verstanden, dass du das durchaus händisch machen wolltest.

Kay Martinen

unread,
Nov 22, 2023, 3:40:03 PM11/22/23
to
Am 22.11.23 um 19:20 schrieb Diedrich Ehlerding:
> Kay Martinen meinte:
>
>>>> Gibt es eine stelle an der man einen bestimmten dienst (erneut)
>>>> deaktivieren kann falls der nach einem 'apt upgrade' neu gestartet
>>>> wurde?
>>>
>>> sudo systemctl disable <xxxx>.service (evtl. "... disable --now ...",
>>> wenn du ihn auch in der laufenden Sitzung schon loswerden willst)
>>
>> Ja ich weiß. Aber das hilft nur wenn man es danach händisch macht.
>> Denn nach einem upgrade läuft der meist dennoch wieder. Der ignoriert
>> also das disable.
>
> Ja, du suchtest ja auch nach "erneut deaktivieren" - das hatte ich so
> verstanden, dass du das durchaus händisch machen wolltest.

Wollte ich eben nicht. Das "automatisch" im Topic war dir da nicht
deutlich genug? ;)

Diedrich Ehlerding

unread,
Nov 23, 2023, 11:21:57 AM11/23/23
to
Kay Martinen meinte:

>> Ja, du suchtest ja auch nach "erneut deaktivieren" - das hatte ich so
>> verstanden, dass du das durchaus händisch machen wolltest.
>
> Wollte ich eben nicht. Das "automatisch" im Topic war dir da nicht
> deutlich genug? ;)

Nein. Ich lese die Bodies, das Subject ist bei längeren THreads meist
völlig irrelevant geworden.

Kay Martinen

unread,
Nov 24, 2023, 12:00:03 PM11/24/23
to
Am 23.11.23 um 17:21 schrieb Diedrich Ehlerding:
> Kay Martinen meinte:
>
>>> Ja, du suchtest ja auch nach "erneut deaktivieren" - das hatte ich so
>>> verstanden, dass du das durchaus händisch machen wolltest.
>>
>> Wollte ich eben nicht. Das "automatisch" im Topic war dir da nicht
>> deutlich genug? ;)
>
> Nein. Ich lese die Bodies, das Subject ist bei längeren THreads meist
> völlig irrelevant geworden.

Dann scheint dein Bildschirm zu schmal zu sein. Diese ist maximal 5
Stufen tief und das passt sogar auf meinem Laptopschirm komplett drauf.

Marc Haber

unread,
Nov 24, 2023, 12:20:51 PM11/24/23
to
Marcel Mueller <news.5...@spamgourmet.org> wrote:
>Am 21.11.23 um 17:46 schrieb Kay Martinen:
>> Und ich habe es mehrfach erlebt das der nach einem update seines
>> (dritt)pakets auf ein mal wieder läuft.
>
>Ja, die Installer stellen normalerweise den Zielzustand so gut wie
>möglich wieder her.

Das ist in Debian eigentlich policywidrig, einen Dienst abzuschalten
ist eine Entscheidung des lokalen Admins und die ist zu respektieren.

Bei einem aus Debian stammenden Paket gäbe es eine Art
Qualitätskontrolle, bei Paketen aus Dritt-Repositories natürlich
nicht. Go figure.

>> Gibt es da irgendwo einen passenden Hook/script o.a. im apt Ablauf wo
>> man ein systemctl disable/stop teamviewer.service einfügen könnte?
>
>Da bin ich überfragt.

Ich finde die Idee mit einem systemd-Override sehr sexy, da könnte man
eine passende Condition einwerfen.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Marc Haber

unread,
Nov 24, 2023, 12:21:26 PM11/24/23
to
Kay Martinen <use...@martinen.de> wrote:
>Und mit 'mask' habe ich noch keine Erfahrungen wie man das anwendet. Und
>ob es wirklich "härter" abschaltet.

So hart dass Du es nichtmal mehr manuell starten kannst. Das wäre Dir
also zu viel.

Marc Haber

unread,
Nov 24, 2023, 12:21:59 PM11/24/23
to
Arno Welzel <use...@arnowelzel.de> wrote:
>Kay Martinen, 2023-11-21 17:46:
>
>[...]
>> Was ich also will ist entweder das neustarten verhindern oder zuletzt
>> automatisch zu schauen ob er evtl. aktiv ist und ihn wieder zu
>> deaktivieren und zu stoppen.
>>
>> Gibt es da irgendwo einen passenden Hook/script o.a. im apt Ablauf wo
>> man ein systemctl disable/stop teamviewer.service einfügen könnte?
>
>Evtl. mit Triggern:
>
><https://wiki.debian.org/DpkgTriggers>

Dazu müsste er der Maintainer des Pakets sein.

Peter J. Holzer

unread,
Nov 24, 2023, 1:20:03 PM11/24/23
to
On 2023-11-24 16:53, Kay Martinen <use...@martinen.de> wrote:
> Am 23.11.23 um 17:21 schrieb Diedrich Ehlerding:
>> Nein. Ich lese die Bodies, das Subject ist bei längeren THreads meist
>> völlig irrelevant geworden.
>
> Dann scheint dein Bildschirm zu schmal zu sein. Diese ist maximal 5
> Stufen tief und das passt sogar auf meinem Laptopschirm komplett drauf.

Ich wollte dir schon für diese Bestätigung von Diedrichs These danken,
aber dann ist mir aufgefallen, dass für Deine Antworten offenbar nicht
nur das Subject sondern auch der Body irrelevant ist.

hp

Andreas Kohlbach

unread,
Nov 24, 2023, 2:32:21 PM11/24/23
to
On Fri, 24 Nov 2023 19:20:01 +0100, Peter J. Holzer wrote:
>
> On 2023-11-24 16:53, Kay Martinen <use...@martinen.de> wrote:
>> Am 23.11.23 um 17:21 schrieb Diedrich Ehlerding:
>>> Nein. Ich lese die Bodies, das Subject ist bei längeren THreads meist
>>> völlig irrelevant geworden.
>>
>> Dann scheint dein Bildschirm zu schmal zu sein. Diese ist maximal 5
>> Stufen tief und das passt sogar auf meinem Laptopschirm komplett drauf.

Aber *liest* Du sie auch?

Ich in der Regel (nach einigen Tagen) nicht mehr. Weil auch viele Poster
diese kaputt machen, weil nicht in der Lage, "...(was:)..." richtig
einzusetzen.

Den Vogel schießen nicht auf Englisch gestellte Outlook (Express) dazu in
Emails ab, wenn sie "AW:" im Betreff setzen, wenn es vorher noch nicht
stand. Ich hatte schon "AW: Re: AW: Re: AW: Re" in Betreffs. Irgendwann
konnte Folding auch nichts mehr retten.

Mein Hinweis, den Microsoft-Müll doch bitte eco-friendly zu entsorgen,
wurde nicht nachgekommen. "Den muss ich hier bei der Arbeit verwenden".

> Ich wollte dir schon für diese Bestätigung von Diedrichs These danken,
> aber dann ist mir aufgefallen, dass für Deine Antworten offenbar nicht
> nur das Subject sondern auch der Body irrelevant ist.

War das eine freundliche Formulierung für einen anstehenden Plonk?
--
Andreas

Marcus Jodorf

unread,
Nov 25, 2023, 11:35:09 PM11/25/23
to
Marc Haber <mh+usene...@zugschl.us> schrieb:

> Arno Welzel <use...@arnowelzel.de> wrote:
>> Kay Martinen, 2023-11-21 17:46:
>>
>> [...]
>>> Was ich also will ist entweder das neustarten verhindern oder
>>> zuletzt automatisch zu schauen ob er evtl. aktiv ist und ihn wieder
>>> zu deaktivieren und zu stoppen.
>>>
>>> Gibt es da irgendwo einen passenden Hook/script o.a. im apt Ablauf
>>> wo man ein systemctl disable/stop teamviewer.service einfügen
>>> könnte?
>>
>> Evtl. mit Triggern:
>>
>> <https://wiki.debian.org/DpkgTriggers>
>
> Dazu müsste er der Maintainer des Pakets sein.

Evtl. über apt trigger.
Ich hab z.B. über /etc/apt/apt-conf.d/<script>
und dort über
Dpkg::Pre-Install-Pkgs

ein Script eingeklinkt, daß bei jedem Package install oder remove
aufgerufen wird.
Das Script bekommt dann automatisch als Übergabeparameter vom System
package name, old version, change direction, new version, action
(Protokoll Version 2)
bzw.
package name, old version, old version arch, old version multi-arch
type, change direction, new version, new version arch, new version
mult-arch type, action (aktuelle Protokoll Version 3)

Ich mache da etwas komplizierteres Zeug wie alle Pfade eines zu
installierenden oder zu entfernen Paketes zu ermitteln und das gegen
alle vorhandenen Filesystem Volumes zu matchen und entsprechend
Snapshots auszulösen.

Aber da könnt man sicherlich auch einfach bei package name auf „teamviewer“
matchen. Wenn action dann „**CONFIGURE**“ ist, was einer neuen
Paketinstallation entspricht, könnte man vermutlich einfach entsprechend
systemctl disable aufrufen. Vermutlich mit nötiger Verzögerung/Sleep, damit das
erst nach vollständiger Installation erfolgt.
Sollte aber prinzipiell möglich sein.


Gruß,

Marcus
⚂⚃

Kay Martinen

unread,
Nov 27, 2023, 1:50:03 PM11/27/23
to
Am 26.11.23 um 05:30 schrieb Marcus Jodorf:
> Marc Haber <mh+usene...@zugschl.us> schrieb:
>
>> Arno Welzel <use...@arnowelzel.de> wrote:
>>> Kay Martinen, 2023-11-21 17:46:
>>>
>>> [...]
>>>> Was ich also will ist entweder das neustarten verhindern oder
>>>> zuletzt automatisch zu schauen ob er evtl. aktiv ist und ihn wieder
>>>> zu deaktivieren und zu stoppen.
>>>>
>>>> Gibt es da irgendwo einen passenden Hook/script o.a. im apt Ablauf
>>>> wo man ein systemctl disable/stop teamviewer.service einfügen
>>>> könnte?
>>>
>>> Evtl. mit Triggern:
>>>
>>> <https://wiki.debian.org/DpkgTriggers>
>>
>> Dazu müsste er der Maintainer des Pakets sein.

Bin ich nicht!

> Evtl. über apt trigger.
> Ich hab z.B. über /etc/apt/apt-conf.d/<script>
> und dort über
> Dpkg::Pre-Install-Pkgs

Gibt es auch Post-Install-Pkgs? Das schiene mir passender. Es soll ja
nur NACH dem updatelauf wieder automatisch vom neustarten/laufen
gehindert werden.

> ein Script eingeklinkt, daß bei jedem Package install oder remove
> aufgerufen wird.
> Das Script bekommt dann automatisch als Übergabeparameter vom System
> package name, old version, change direction, new version, action

> Aber da könnt man sicherlich auch einfach bei package name auf „teamviewer“
> matchen. Wenn action dann „**CONFIGURE**“ ist, was einer neuen
> Paketinstallation entspricht, könnte man vermutlich einfach entsprechend
> systemctl disable aufrufen. Vermutlich mit nötiger Verzögerung/Sleep, damit das
> erst nach vollständiger Installation erfolgt.
> Sollte aber prinzipiell möglich sein.

Interessante Idee, nur das mit dem sleep kommt mir zu wackelig vor. Gut,
man könnte sicher auch eine halbe stunde vorgeben, müsste dann aber wohl
nicht nur disable und stop sondern ggf. auch mask absetzen. Und wenn
doch mal vieleviele Pakete auf einmal kommen reicht's vielleicht doch
nicht. Immerhin sollten von teamviewer selbst keine weiteren Pakete
abhängen. Damit müsste es egal sein wenn der ggf. mitten im updaten
gekillt würde, Oder?

Post-Install wäre dann doch ein Trigger der immer danach was auslöst.
Gesehen habe ich solche triggermeldungen bei libc, neuem kernel,
mime-verknüpfungen oder Desktop-sachen bei update oder neu
Installationen schon.

Marcus Jodorf

unread,
Nov 27, 2023, 6:51:09 PM11/27/23
to
Kay Martinen <use...@martinen.de> schrieb:

>> Evtl. über apt trigger.
>> Ich hab z.B. über /etc/apt/apt-conf.d/<script>
>> und dort über
>> Dpkg::Pre-Install-Pkgs
>
> Gibt es auch Post-Install-Pkgs? Das schiene mir passender. Es soll ja
> nur NACH dem updatelauf wieder automatisch vom neustarten/laufen
> gehindert werden.

<https://wiki.debian.org/AptConfiguration>

evtl.:
Dpkg::Post-Invoke {"mycommand";};: executes mycommand after apt calls
dpkg

aber habe ich mir noch nicht näher angeschaut.

<https://askubuntu.com/questions/869219/how-can-i-run-a-script-after-a-specific-package-is-upgraded>



> Post-Install wäre dann doch ein Trigger der immer danach was
> auslöst. Gesehen habe ich solche triggermeldungen bei libc, neuem
> kernel, mime-verknüpfungen oder Desktop-sachen bei update oder neu
> Installationen schon.

Das sind die Dpkg triggers, die Marc erwähnt hat.


Gruß,

Marcus
⚂⚃
0 new messages