Wie man die Desktopnotifications für Updates los wird

Vor einigen Wochen habe ich GEDIT F21 auf die F20 Version gedowngradet, weil das Programm unerträglich unbrauchbar gemacht wurde. Seitdem Tag nervt mich der Desktop mit Notifications, daß genau dieses Paket komplett veraltet sein und ich doch die Updates einspielen solle.

Natürlich hatte ich YUM erzählt, die Updates nicht einzuspielen. Für die Desktopanwendung „Software“ aka PackageKit gilt die YUM Einstellung aber nicht, die macht das gerne selbstständig. Da PackageKit keine Configeinstellungen dafür parat hat, kann man es nur als Root abschalten :

systemctl stop packagekit
systemctl disable packagekit

Bevor man das macht, sollte man sicherstellen, daß man so einen CronJob z.b. als /etc/cron.d/yum angelegt hat:

 1 */2 * * * root yum -y update >>/var/log/messages

Sonst kommen nämlich gar keine Updates mehr an und das möchten man gar nicht haben.

Viren mit Minimalanschreiben

„Guten Tag.Dokument“ und ein ZIP File, das ist alles was man heute bekommt, wenn man von Kriminellen mit Schadsoftware per Email beglückt wird.

Schlechte Zeiten für Emailanalysten wie mich, oder doch nicht ? 🙂

Received: from atlantic704.dedicatedpanel.com (50-78-157-221-static.hfc.comcastbusiness.net [50.78.157.221])
(Authenticated sender: u000458)
by mx2.bredband2.com (Postfix) with ESMTPA id A4532235FE
for ; Wed, 22 Jul 2015 03:34:13 +0200 (CEST)

Spannend wird es allerdings, wenn man mal die Domain aufruft, die als Servername beim Absenden des Virus benutzt wurde:

http://atlantic704.dedicatedpanel.com/

Es erscheint eine Liste mit IP Adressen und Portnummer:

216.244.65.203:1080
212.57.179.29:2214
202.119.199.147:1080
?90.?7.2?4.4?:80?0
?0.2?0.2?2.6?:24?84
?90.?03.?98.?75:?080
?19.?7.1?1.1?7:1?130
?0.2?0.2?2.9?:33?19
?20.?4.2?2.1?4:8?80
?19.?10.?7.2?0:8?80
?90.?18.?9.2?2:3?28
?90.?44.?28.?98:?128
?90.?4.2?4.3?:80?0
?23.?03.?3.1?6:3?948
?19.?7.1?1.1?9:1?305
?77.?4.1?3.3?:31?8
?18.?2.2?7.1?0:1?279
?90.?7.7?.16?808?
?01.?11.?40.?6:8?80
?90.?05.?22.?8:8?80
?01.?09.?55.?5:8?80
?86.?8.1?8.6?:80?0
?0.2?0.2?2.6?:10?46
?23.?52.?3.2?7:3?965
?83.?32.?5.4?:13?89
?86.?3.1?1.1?2:8?80
?90.?07.?60.?41:?080
?00.?4.6?26:?080
?90.?06.?1.2?2:8?80
… geht noch 12 Bildschirmseiten weit runter…

Da nur wenige IPs vollständig sind, schauen wir uns die ersten drei mal an :

216.244.65.203:1080 ( sb4umail21.info )
212.57.179.29:2214 ( Instrument-making factory of City of Trekhgorny
)
202.119.199.147:1080 ( China University of Mining and Technology
)

202.119.199.147:1080 und 216.244.65.203:1080 scheinen jeweils ein SOCKs Proxy zu sein. Leider kann man die Ports aus Deutschland nicht erreichen, da die Dienste wohl abgeschaltet sind.

Da auch der RDQ ( steht für Relational Databases and Query Language ) Port 2214 nicht antworten möchte, kann man nur spekulieren, was diese Liste darstellen soll.

Vielleicht bekommt ja der eine oder andere Neugierige raus, was das darstellt und wieso die Ips verstümmelt sind. Das mir das jetzt keiner als Aufforderung zu einer möglichen Straftat missversteht, klar!

Die Sudomains atlantic70X…. führen übrigens zu den merkwürdigsten Seiten u.a. auch Webseiten von Switchen 😉 Wenn man mal mehr Zeit hätte 😉

Hacking Team

Tja, jetzt ist der Alptraum Wahrheit geworden, denn Wikileaks hat die gesamte Emailkorrespondenz von Hacking Team in einer durchsuchbaren Datenbank zur Verfügung gestellt.

Wer ist „Hacking Team“ oder auch „hacked Team“, wie manche neuerdings sagen ?

Hacking Team ist eine italienische Firma, die Exploits erstellt, verteilt und gleich noch die passende Überwachungssoftware zur Verfügung stellt. Jedem der zahlt versteht sich. Da man seit einigen Tagen die Kundenliste einsehen kann, kann man genau sagen, wer zum Kundenkreis gehört und das sind keine netten Regime.

Wer sich selbst einmal deren Emailkorrespondenz durchlesen will :

https://wikileaks.org/hackingteam/emails/

Such mal nach NICE.com, Android und Exploit, dann seht ihr wie diese Überwachungsfutzis wirklich drauf sind.

Viele Emails sind in italienisch verfaßt, weils interne Mails sind. Aber wofür gibts Google Translate 🙂

DNF: das neue YUM, oder?

DNF ist seit Fedora 21 das Tool für Softwareupdates.  DNF soll die Probleme von YUM lösen, indem es andere Algorithmen zur Abhängigkeitsauflösung anwendet, unter anderem.

Zunächst mal muß man keine Angst vor der Umstellung haben, denn DNF ist sogut wie es geht YUM kompatibel, was die Befehle in der Shell angeht, und YUM kann zur Not auch weiter verwenden. Das geht so gut, daß die gleichen alten Probleme auf die gleiche Art gelöst werden müssen.

Ich hatte ja mal gezeigt, wann und wie man Updates abschaltet:

# cat /etc/yum.conf 
[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3
exclude=qmmp* gedit*
...

DNF gibt sich da etwas schlanker :

# cat /etc/dnf/dnf.conf 
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=true
exclude=gedit*

Es macht aber am Ende genau das gleiche.

Warum habe ich jetzt Gedit von weiteren Updates ausgenommen ?

Für alle die es nicht wissen, Gedit ist der standardmäßig installiere Texteditor für Gnome. In Fedora 20 war er : schlank, schlicht, schnell, nützlich. Mit dem Update auf Fedora 21 fallen mir nur folgende Attribute ein: Mozilladesign, unnütz, bloated (rpms), absoluter Schrott.

Gedit war in Fedora 20 der mit Abstand nützlichste Editor, weil er optisch nicht so überladen war wie z.b. Blue Fish, aber dennoch alles hatte : Tabs, Syntaxhighlighting, Rechtschreibkorrektur und Platz!

Die neue Version ist umgangssprachlich für den Arsch. Die Menüführung ist abenteuerlich und komplett umständlich. Die Icons sind weg, man müßte jetzt Menüfunktionen aufrufen. Das Layout ist überdesigned zur absoluten Nutzlosigkeit verschönt. Ganz sicher mußte der Designer diese Änderungen nicht mit seinem Geditdesign machen, sonst wäre ihm aufgefallen, was für einen Müll er da produziert. Ist ja häufig so, daß Produkte bis zur Unkenntlichkeit umdesigned werden, nur damit man mal was gemacht hat als Hersteller. Ob das Update am Ende nützlich war, interessiert doch am Ende keinen mehr, Hauptsache es ist neu.

Zu allem übel, kann man den Gedit nicht optisch auf nützlich zurückstellen, weswegen es tatsächlich nur zwei Lösungen gab: 1. Auf einen anderen Texteditor umsteigen oder 2. yum erase „gedit*“; rpm -i –nodeps gedit*f20*rpm .

Jetzt gibt es zwei Wege an die RPMS zu kommen:

1. KOJI benutzen. Das hat aber trotzdem noch viel Gesuche zur Folge.

oder 2. Einfach im alten Fedora 20 Repository nachsehen:

# cat /etc/yum.repos.d/fedora.repo 
[fedora]
name=Fedora $releasever - $basearch
failovermethod=priority
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
enabled=1
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False
...

Die BaseURL zeigt wird nun einfach etwas angepaßt und dann im Browser aufgerufen ( bitte: Nicht bei Google eingeben, sondern in die Adressleiste des Browsers! ). Das wäre dann diese hier:

http://download.fedoraproject.org/pub/fedora/linux/releases/20/Everything/x86_64/os/

Der Repobesuch mit dem Browser erlaubt auch eine einfache Navigation durch die Repos, was bei Koji nicht der Fall ist. Damit kann man viele Programme sehr viel schneller finden, als im Koji Buildsystem.

Nachdem die RPMS auf der Platte geparkt wurden, müssen Sie dan mit rpm -i --nodeps installiert werden, weil die Abhängikeiten im RPM natürlich auf Fedora20 lauten und nicht auf Fedora 21 Pakete. Wer sich mit dem Gedanken trägt sein Gedit auch zu downgraden, der sollte folgende Pakete nehmen, die restlichen sind so schwer abhängig, das klappt vermutlich nicht:
2588 -rw-rw-r--. 1 marius marius 2646356  5. Jul 23:26 gedit-3.10.2-1.fc20.x86_64.rpm
  16 -rw-rw-r--. 1 marius marius   13944  6. Jul 00:04 gedit-beesu-plugin-0.4-13.fc20.x86_64.rpm
 124 -rw-rw-r--. 1 marius marius  124560  6. Jul 00:04 gedit-code-assistance-0.2.0-4.fc20.x86_64.rpm
  56 -rw-rw-r--. 1 marius marius   53584  6. Jul 00:04 gedit-cossa-3.2.0-6.fc20.x86_64.rpm
 836 -rw-rw-r--. 1 marius marius  853444  5. Jul 23:26 gedit-plugins-3.10.0-1.fc20.x86_64.rpm
  20 -rw-rw-r--. 1 marius marius   16920  5. Jul 23:26 gedit-zeitgeist-3.10.2-1.fc20.x86_64.rpm

Damit ist Gedit dann wieder einsetzbar. Sieht zwar nicht mehr so schick auch wie früher, aber es tut seinen Job.