1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Aufräumen von Prozessen beim…

Kein Bug, nur Kommunikationsproblem

  1. Thema

Neues Thema Ansicht wechseln


  1. Kein Bug, nur Kommunikationsproblem

    Autor: Sharra 30.05.16 - 15:18

    Es wurde geändert, und keiner hats gelesen. Das ist das Problem hier. Wenn mans wieder ändern kann, okay. Man hätte es aber auch einfach lassen können. Wer möchte, dass alles gekillt wird, kanns ja aktivieren.

  2. Re: Kein Bug, nur Kommunikationsproblem

    Autor: HiddenX 30.05.16 - 15:40

    Es ist aber das logische Verhalten. Warum sollte man eine Verbesserung zurückhalten um den 7 Leuten die sich dran stören nicht auf die Füße zu treten, sollen sie halt den Changelog lesen oder Googlen was das Problem ist. (Ja, sind vermutlich mehr als 7, aber dennoch ist das kein Grund ein logisches Verhalten nicht zu aktivieren nur weil einige Personen dann einen Config-Eintrag ändern müssen)



    1 mal bearbeitet, zuletzt am 30.05.16 15:42 durch HiddenX.

  3. Re: Kein Bug, nur Kommunikationsproblem

    Autor: Sharra 30.05.16 - 15:42

    HiddenX schrieb:
    --------------------------------------------------------------------------------
    > Es ist aber das logische Verhalten. Warum sollte man eine Verbesserung
    > zurückhalten um den 7 Leuten die sich dran stören nicht auf die Füße zu
    > treten, sollen sie halt den Changelog lesen oder Googlen was das Problem
    > ist.

    Ob es eine Verbesserung ist, liegt, voll und ganz, im Auge des Betrachters. Für manche ist es fraglos eine Verbesserung. Für andere ist es Schwachsinn.

  4. Re: Kein Bug, nur Kommunikationsproblem

    Autor: HiddenX 30.05.16 - 15:43

    Sharra schrieb:
    --------------------------------------------------------------------------------
    > Ob es eine Verbesserung ist, liegt, voll und ganz, im Auge des Betrachters.
    > Für manche ist es fraglos eine Verbesserung. Für andere ist es Schwachsinn.
    Sicher, aber dann sollte man abwägen welche Gruppe wohl größer ist. Und logisch betrachtet macht es eindeutig Sinn alles zu killen was ein User gestartet hat wenn er sich abmeldet.

  5. Re: Kein Bug, nur Kommunikationsproblem

    Autor: yoyoyo 30.05.16 - 15:55

    Es war ja auch vorher (nahezu) so, weshalb ja nun fast jeder Tmux oder Screen benutzt. Das ist nicht wegen der (höhö) tollen Oberfläche der Fall. Und den tmux daemon dann wieder an einen daemon ketten, der selbst wieder eine logind session für den Benutzer aufmacht .. hat mit KISS auf jeden Fall nichts zu tun.

    Scheint fast als würde man mit aller Macht versuchen sich den Zorn der Admins aufzuhalsen.

    Die Großzahl der professionellen (im Sinne von da arbeitet jemand mit) remote login sessions sollen weiter laufen, wenn die Verbindung (kurz) ausgeloggt wird oder einen Timeout erleidet. Das ist die ernsthafte und nicht theoretische Anforderung.

  6. Re: Kein Bug, nur Kommunikationsproblem

    Autor: xUser 30.05.16 - 16:01

    yoyoyo schrieb:
    --------------------------------------------------------------------------------
    > Es war ja auch vorher (nahezu) so, weshalb ja nun fast jeder Tmux oder
    > Screen benutzt. Das ist nicht wegen der (höhö) tollen Oberfläche der Fall.
    > Und den tmux daemon dann wieder an einen daemon ketten, der selbst wieder
    > eine logind session für den Benutzer aufmacht .. hat mit KISS auf jeden
    > Fall nichts zu tun.

    Nein, dass ist eine "das ging vor 30 Jahren schon so" Argumentation, die in die heutige Systemlandschaft nicht mehr reinpasst.

    Wer in einer eigenen Session laufen möchte (screen, tmux, etc) muss diese auch selbst aufbauen und nicht auf implizites Verhalten setzen.

    > Die Großzahl der professionellen (im Sinne von da arbeitet jemand mit)
    > remote login sessions sollen weiter laufen, wenn die Verbindung (kurz)
    > ausgeloggt wird oder einen Timeout erleidet. Das ist die ernsthafte und
    > nicht theoretische Anforderung.

    Ein Verbindungsabbruch ist etwas anderes als ein Logout. Und ein Logout sollte (muss) auch sein Session-Scope aufräumen; wer einen anderen Scope wünscht, muss entweder einen neue Session aufmachen (PAM, etc) oder dies dem Session Manager mitteilen.

  7. Re: Kein Bug, nur Kommunikationsproblem

    Autor: chseidel 30.05.16 - 16:46

    Nix da.

    Das erste gewünschte Verhalten ist eine Persistierung des Sessionzustandes über den Logout hinweg. Nur weil du dein Mobile ausschaltest, willst du nicht deine Chats - SMS, Whatsapp, whatever - gelöscht haben.

    Bevor man also ach so tolle "Das dient der logischen Geschlossenheit des Systembereiches X und verhindert theoretische Probleme die ein Großteil der Welt nicht hat" - macht, erstmal mit den Nutzern - hier Admins - reden!

    Das kommt in letzter Zeit bei den Entwicklern viel zu kurz!

    Dann hätte man gewusst, das viele Admins (Achtung, zweiter Use Case!) screen &al nutzen um ein länger andauerndes Kommando in Ruhe abzusetzen, um dann nach der verdienten Pause von einem anderen Ort(!) aus weiterarbeiten zu können.
    Oder trotz wackeliger Verbindung sinnvoll am System arbeiten zu können.
    So sieht die Praxis aus.

    Also, wenn ihr aufräumen wollt, bitte schön. Ich bin da ganz bei euch. Nur will ich weiterhin sinnvoll am System arbeiten können. Ohne Hirnverrenkungen.
    Was da gerade passiert ist wie eine Wahlwiederholung, die man vor dem Anruf anmeldemn muß.

  8. Re: Kein Bug, nur Kommunikationsproblem

    Autor: brainslayer 30.05.16 - 21:58

    Einen Daemon starten zu können ohne das er gekillt wird wenn man sich ausloggt ist ein Feature was nicht nur wenige benötigen, sondern Alle. ICH SAGE ALLE. Dieses Feature ist nutzlos und macht Linux kaputt. Damit ist es per definion ein Bug, weil dieses Verhalten so in Unixoiden Systemen nicht vorgesehen ist

  9. Re: Kein Bug, nur Kommunikationsproblem

    Autor: xUser 30.05.16 - 22:14

    brainslayer schrieb:
    --------------------------------------------------------------------------------
    > Dieses Feature ist nutzlos und macht Linux kaputt. Damit ist es
    > per definion ein Bug, weil dieses Verhalten so in Unixoiden Systemen nicht
    > vorgesehen ist

    Weil es bei Unix-Systemen traditionell kein Session-Management gegen hat. Dies wurde mit loginctl nachgerüstet und macht jetzt genau das was es soll:
    * Sessions sauber trennen
    * Resourcen zwischen den Sessions verwalten
    * Leftovers aufräumen

    Wenn ein Prozess als Service laufen soll, dann starte ihn einfach als Service, anstatt das implizite Verhalten auszunutzen, dass nach einem Doppel-Fork ein Prozess nicht mit seinem Urgroßvater getötet wird, wenn der Vaterprozess sich schon beendet hat.

  10. Re: Kein Bug, nur Kommunikationsproblem

    Autor: brainslayer 30.05.16 - 22:20

    hast du schonmal einen server betrieben? das ist ein komplett nutzloses feature und sorgt dafür das ein server nicht mehr server sein kann. ich log mich ein, starte meinen sql dienst neu. log mich aus. ups alles weg. son shit.
    leftovers gehören nicht augeräumt weil man sie mutwillig platziert hat. es sind keine leftovers. das problem ist das systemd gar nicht weis was leftovers sind und was nicht und killt einfach alles was ihm passt. sessions waren schon vorher sauber getrennt. und resourcen wurden auch schon immer zwischen sessions verwaltet. weil das systemd überhaupt nicht tut. resourcen verwaltet der kernel. systemd ist nichts weiter als eine gott applikation die am anfang gestartet wird und dir vorschreibt wie du dein system zu verwenden hast und zwar so und nicht anders und schon gar nicht so wie früher und erst recht nicht kompfortabel und angenehm. schon mal start/stop bootprozesse in systemd konfiguriert? du kriegst das kotzen

  11. Re: Kein Bug, nur Kommunikationsproblem

    Autor: xUser 30.05.16 - 22:40

    brainslayer schrieb:
    --------------------------------------------------------------------------------
    > hast du schonmal einen server betrieben? das ist ein komplett nutzloses
    > feature und sorgt dafür das ein server nicht mehr server sein kann. ich log
    > mich ein, starte meinen sql dienst neu. log mich aus. ups alles weg. son
    > shit.

    Du hast überhaupt nicht verstanden worum es geht.

    > leftovers gehören nicht augeräumt weil man sie mutwillig platziert hat. es
    > sind keine leftovers. das problem ist das systemd gar nicht weis was
    > leftovers sind und was nicht und killt einfach alles was ihm passt.

    systemd kill gar nichts, dass mache loginctl

    > sessions waren schon vorher sauber getrennt. und resourcen wurden auch
    > schon immer zwischen sessions verwaltet. weil das systemd überhaupt nicht
    > tut. resourcen verwaltet der kernel.

    Nein, Prozesse waren getrennt, aber eben keine Sessions (außer du definierst dir eine Shell als Session neu).

    Nicht jede Resource wird vom Kernel vollständig verwalten, e.g. audio Geräte. Woher soll der Kernel wissen welcher User jetzt auf welches Audio Gerät Zugriff hat? Wie schaut es mit Druckern, USB-Sticks (insbesondere an Servern, ... ja tun Leute), etc. aus

    Nur weil du vom Kernel das prinzipielle Recht zum nutzen einer Resource hast, heißt dies nicht, dass du immer darauf Zugriff hast.

    > systemd ist nichts weiter als eine
    > gott applikation die am anfang gestartet wird und dir vorschreibt wie du
    > dein system zu verwenden hast und zwar so und nicht anders und schon gar
    > nicht so wie früher und erst recht nicht kompfortabel und angenehm.

    systemd ist ein Prozessverwaltung, hat aber mit loginctl nicht viel zu tun.

    > schon
    > mal start/stop bootprozesse in systemd konfiguriert? du kriegst das kotzen

    100x mal besser als init.d Script voll von implizitem Verhalten und Shell Hacks *kotz*

    Wo ist das Problem? Einfach ein simples Template nehmen, im Zweifel per
    $ systemctl cat foo.service
    ein paar Beispiel ausgeben.

    ---------------->8--------------------- /etc/systemd/system/foo.service
    [Unit]
    Description=My Foo Server
    After=syslog.target
    After=network.target

    [Service]
    Type=simple
    User=service-foo
    Group=service-foo

    #ExecStartPre=/usr/bin/whatever-pre
    ExecStart=/usr/bin/my-service
    #ExecStartPost=/usr/libexec/whatever-post

    # Give a reasonable amount of time for the server to start up/shut down
    TimeoutSec=300

    # Place temp files in a secure directory, not /tmp
    PrivateTmp=true

    [Install]
    WantedBy=multi-user.target
    ----------------8<---------------------

    $ systemctl enable foo.service
    $ systemctl start foo.service
    $ systemctl status -l foo.service

  12. Re: Kein Bug, nur Kommunikationsproblem

    Autor: brainslayer 30.05.16 - 22:57

    das ist kein shellscript. sondern ein propertiäres config format. es erlaubt mir nicht zu tun was ich möchte sondern schreibt mir vor was ich darf. z.b. ein programm starten. aber ich habe das gefühl das ein bash script irgendwie damals mehr konnte. woher der kernel weis welcher user zugriff auf welches audiogerät hat? mmh anhand der uid und der guid die jedem prozess anhängt und bei jedem filezugriff mitgeführt wird. ahso und auch bei jedem ioctl und systemcall ist es möglich diesen zu ermitteln. alle zugriffe auf die peripherie gehen über den kernel und der kernel kennt die nutzer und gruppen id jedes prozesses der darauf zugreift. sorry. ich programmiere schon sehr lange mit an treibern im linux kernel genauso wie an anderen dingen die ihn betreffen. ich weis sehr gut wie er funktioniert. für rechtemanagement, resourcen und resourcenschutz, thema mmu, genauso wie rechte beim filesystemzugriff etc. das macht kein systemd. das macht der kernel. der verhindert das du auf dinge zugreifst wo du nix zu suchen hast. würde das system im userspace machen wäre das ein gewaltiges sicherheitsproblem. speicherschutz hat seine vorteile, desswegen läuft der kernel isoliert vom userspace, damit kein kaputtes programm ihn manipulieren kann (vorausgesetzt er hat keine sicherheitslücke)

  13. Re: Kein Bug, nur Kommunikationsproblem

    Autor: nille02 30.05.16 - 22:59

    brainslayer schrieb:
    --------------------------------------------------------------------------------
    > das ist kein shellscript.

    Zum Glück.

  14. Re: Kein Bug, nur Kommunikationsproblem

    Autor: brainslayer 30.05.16 - 23:03

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > brainslayer schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > das ist kein shellscript.
    >
    > Zum Glück.
    spiel weiter mit deinem ubuntu und lass die profis ihre arbeit machen

    oder anders ausgedrückt. Tolles Argument Junge. Frei nach dem Motto ich weis gar nicht was ein shellscript ist und wofür man das braucht, desswegen muss es weg



    1 mal bearbeitet, zuletzt am 30.05.16 23:05 durch brainslayer.

  15. Re: Kein Bug, nur Kommunikationsproblem

    Autor: xUser 30.05.16 - 23:06

    brainslayer schrieb:
    --------------------------------------------------------------------------------
    > das ist kein shellscript.

    Das ist gerade die Idee hinter systemd ... nicht ein verfrickelts Shell Skript, welches außer dem Admin keiner (schnell) versteht, sondern ein klares Konfigurationsformat, welches auch mit dem Server nicht Vertraute schnell und zuverlässig analysieren können.

    > sondern ein propertiäres config format. es
    > erlaubt mir nicht zu tun was ich möchte sondern schreibt mir vor was ich
    > darf. z.b. ein programm starten. aber ich habe das gefühl das ein bash
    > script irgendwie damals mehr konnt.

    Klar kann ein Bash Script mehr, aber dies will man nicht.

    > woher der kernel weis welcher user
    > zugriff auf welches audiogerät hat? mmh anhand der uid und der guid die
    > jedem prozess anhängt und bei jedem filezugriff mitgeführt wird. ahso und
    > auch bei jedem ioctl und systemcall ist es möglich diesen zu ermitteln.
    > alle zugriffe auf die peripherie gehen über den kernel und der kernel kennt
    > die nutzer und gruppen id jedes prozesses der darauf zugreift.

    Darum geht es nicht, sondern darum wer diesen Zugriff konfiguriert und wie sich diese Konfigurationen (schnell) und zuverlässig überprüfen und nachvollziehen lassen.

    > sorry. ich
    > programmiere schon sehr lange mit an treibern im linux kernel genauso wie
    > an anderen dingen die ihn betreffen. ich weis sehr gut wie er funktioniert.
    > für rechtemanagement, resourcen und resourcenschutz, thema mmu, genauso wie
    > rechte beim filesystemzugriff etc. das macht kein systemd. das macht der
    > kernel. der verhindert das du auf dinge zugreifst wo du nix zu suchen hast.
    > würde das system im userspace machen wäre das ein gewaltiges
    > sicherheitsproblem. speicherschutz hat seine vorteile, desswegen läuft der
    > kernel isoliert vom userspace, damit kein kaputtes programm ihn
    > manipulieren kann (vorausgesetzt er hat keine sicherheitslücke)

    loginctl greif auf die Kernelfunktionen zurück, stellt in gewissen Sinne nur ein (sauberes) Interface dafür bereit.

    selbiges gilt für Systemd ... und Hand aufs Herz, wer hat in seinen Shell Script en schon ordentliche Container für alle Dienste definiert?

  16. Re: Kein Bug, nur Kommunikationsproblem

    Autor: nille02 30.05.16 - 23:08

    brainslayer schrieb:
    --------------------------------------------------------------------------------
    > > Zum Glück.
    > spiel weiter mit deinem ubuntu und lass die profis ihre arbeit machen

    Du bist drollig. Siehst du deine faulenden Felle davon schwimmen?
    Durch deine Einstellung und Arroganz schadest du GNU/Linux nur und bist vermutlich auch noch Stolz drauf.

    Aber wenn du ein Profi bist, dann ist es vermutlich schlimmer als alle denken.

  17. Re: Kein Bug, nur Kommunikationsproblem

    Autor: xUser 30.05.16 - 23:14

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > brainslayer schrieb:
    > ---------------------------------------------------------------------------

    > Aber wenn du ein Profi bist, dann ist es vermutlich schlimmer als alle
    > denken.

    Das ist (vermutlich) ein "Profi", der seine Init-Skripte immer so verbastelst, das außer ihm niemand den Server Administrieren kann. Das ist eine Form von Arbeitsplatzsicherung (macht unersetzlich).

    Ein klare und nachvollziehbar Konfiguration ist solchen Leuten ein Dorn im Auge, weil dann könnte ja jeder kommen und den Server administrieren.

    In Zeiten von systemd, docker & co schwimmen diesen Leuten natürlich die Felle davon ;)

  18. Re: Kein Bug, nur Kommunikationsproblem

    Autor: wasdeeh 31.05.16 - 10:11

    brainslayer schrieb:
    --------------------------------------------------------------------------------
    > hast du schonmal einen server betrieben? das ist ein komplett nutzloses
    > feature und sorgt dafür das ein server nicht mehr server sein kann. ich log
    > mich ein, starte meinen sql dienst neu. log mich aus. ups alles weg. son
    > shit.

    Oida. Nein, so funktioniert das nicht.
    Bitte mal in die Basics von Session-Management, loginctl etc. einlesen (oder schaun, wie's z.B. ein Windows-Server macht. Ja, tatsächlich.), bevor du hier so einen kolossalen Dunning-Kruger baust.

  19. Re: Kein Bug, nur Kommunikationsproblem

    Autor: chseidel 31.05.16 - 10:24

    xUser schrieb:
    --------------------------------------------------------------------------------
    > brainslayer schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Dieses Feature ist nutzlos und macht Linux kaputt. Damit ist es
    > > per definion ein Bug, weil dieses Verhalten so in Unixoiden Systemen
    > nicht
    > > vorgesehen ist
    >
    > Weil es bei Unix-Systemen traditionell kein Session-Management gegen hat.
    > Dies wurde mit loginctl nachgerüstet und macht jetzt genau das was es
    > soll:
    > * Sessions sauber trennen
    > * Resourcen zwischen den Sessions verwalten
    > * Leftovers aufräumen
    >
    > Wenn ein Prozess als Service laufen soll, dann starte ihn einfach als
    > Service, anstatt das implizite Verhalten auszunutzen, dass nach einem
    > Doppel-Fork ein Prozess nicht mit seinem Urgroßvater getötet wird, wenn der
    > Vaterprozess sich schon beendet hat.

    [ ] Du weißt was Multics war und was Unix nie sein sollte.
    [ ] Du weißt, daß die Arbeit für die Tonne ist, weil Leute als erstes den Default ändern.
    [ ] Du weißt, daß das Kommunikationsproblem vor der Entwicklung stattgefunden hat.
    [ ] Du weißt, daß man mit relativ wenig Grundwissen und mit i. W. passiven Programmiersprachenkentnissen ein Unix verstehen und betreiben konnte. Jetzt muß man sich immer mehr überkandidelte Objektmodelle reinziehen, bevor man überhaupt irgendwas machen kann.

  20. Re: Kein Bug, nur Kommunikationsproblem

    Autor: wasdeeh 31.05.16 - 15:24

    chseidel schrieb:
    --------------------------------------------------------------------------------
    > xUser schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > brainslayer schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Dieses Feature ist nutzlos und macht Linux kaputt. Damit ist es
    > > > per definion ein Bug, weil dieses Verhalten so in Unixoiden Systemen
    > > nicht
    > > > vorgesehen ist
    > >
    > > Weil es bei Unix-Systemen traditionell kein Session-Management gegen
    > hat.
    > > Dies wurde mit loginctl nachgerüstet und macht jetzt genau das was es
    > > soll:
    > > * Sessions sauber trennen
    > > * Resourcen zwischen den Sessions verwalten
    > > * Leftovers aufräumen
    > >
    > > Wenn ein Prozess als Service laufen soll, dann starte ihn einfach als
    > > Service, anstatt das implizite Verhalten auszunutzen, dass nach einem
    > > Doppel-Fork ein Prozess nicht mit seinem Urgroßvater getötet wird, wenn
    > der
    > > Vaterprozess sich schon beendet hat.
    >
    > [ ] Du weißt was Multics war und was Unix nie sein sollte.

    Tjo, weiter brauchst du eigentlich nicht reden. Wenn das dein erstes (übrigens echt schon verdammt ausgelutschtes) "Argument" ist - warum verwendest du dann überhaupt noch systemd?

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Product Manager Cloud / PaaS / IaaS (m/w/d)
    iWelt GmbH + Co. KG, Eibelstadt
  2. Kundenbeziehungsmanager Service (m/w/d)
    Gladbacher Bank AG, Korschenbroich
  3. Senior Projektmanager (m/w/d) klinische Anwendungen
    Helios IT Service GmbH, Berlin-Buch
  4. IT Service Manager für SaaS-Produkte (w/m/d)
    EnBW Energie Baden-Württemberg AG Holding, Karlsruhe, Köln

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. nur für Prime-Mitglieder
  2. (u. a. Monster Hunter World - Iceborne (DLC) für 18,99€, Horizon Zero Dawn - Complete Edition...
  3. (u. a. Nintendo Switch Lite für 174,99€, Miitopia für 37,99€, Roccat Kone Aimo für 47,50€,
  4. (u. a. Crucial Ballistix Max RGB DDR4-4000 MHz 32GB Kit für 283,99€, Crucial P5 1TB PCIe SSD...


Haben wir etwas übersehen?

E-Mail an news@golem.de


DJI FPV im Test: Adrenalin und Adlerauge
DJI FPV im Test
Adrenalin und Adlerauge

Die DJI FPV verpackt ein spektakuläres Drohnen-Flugerlebnis sehr einsteigerfreundlich. Wir haben ein paar Runden mit 100 km/h gedreht.
Ein Test von Martin Wolf

  1. Quadcopter DJI Air 2S mit großem Sensor für 5,4K-Videos erschienen
  2. DJI Drohnenhersteller plant offenbar Einstieg ins Autogeschäft
  3. Drohne DJI Air 2s soll mit 20 Megapixeln fliegend fotografieren

Telefon- und Internetanbieter: Was tun bei falschen Auftragsbestätigungen?
Telefon- und Internetanbieter
Was tun bei falschen Auftragsbestätigungen?

Bei Telefon- und Internetanschlüssen kommt es öfter vor, dass Verbraucher Auftragsbestätigungen bekommen, obwohl sie nichts bestellt haben.
Von Harald Büring


    Der Fall Anne-Elisabeth Hagen: Lösegeldforderung per Bitcoin-Transaktion
    Der Fall Anne-Elisabeth Hagen
    Lösegeldforderung per Bitcoin-Transaktion

    Der Fall der verschwundenen norwegischen Millionärsgattin Anne-Elisabeth Hagen ist auch ein Krimi um Kryptowährungen und Anonymisierungsdienste.
    Von Elke Wittich und Boris Mayer

    1. Breitscheidplatz-Attentat BKA beendet nach Online-Suche offenbar Analyse von Rufnummer
    2. Rechtsextreme Chats Innenminister löst SEK Frankfurt auf
    3. FBI und BKA Mit gefälschtem Messenger gegen das organisierte Verbrechen