Category Archives: Fedora

Alpaca, Ollama und wie man es missbrauchen kann

Posted on by

Seit letztem Dienstag bastel ich mit lokalen LLM rum. Dazu habe ich Alpaca ausprobiert, daß als Flatpak installiert wurde.

Alpaca, Ollama und wie man es missbrauchen kann

Das zuerst wählt man sich eins oder mehrere Sprachmodelle aus, die man benutzen will:UI Oberfläche mit einer Auswahl von Modellen in einer ListeDanach kann man direkt loslegen, weil Alpca als Frontend für Ollama alles nötige macht:

– Ollama als Dienst starten
– die Modelle vorbereiten und pullen
– eine Eingabeoberfläche mit HTML Ausgabe bereitstellen.

Wer jetzt nur mit dem Modell Spielchen treiben will, kann direkt anfangen. Wer aber ohne die Oberfläche jedes mal starten zu müssen, mit den Modellen interagieren möchte, der sollte Ollama selbst installieren.

Dazu einfach root werden und das Install Script starten. Wenn man bereits 3D-vollständige Grafikkarteninstallationen hat, passiert nicht viel, außer:

– Ollama User wird angelegt
– Systemd Service erstellt
– Ollama initialisiert

Mehr braucht es nämlich gar nicht. Das Ganze wird mit einer einzigen Zeile gestartet:

$ curl -fsSL https://ollama.com/install.sh | sh

Nach dem Start sieht das dann so aus:

$ systemctl status ollama
● ollama.service – Ollama Service
Loaded: loaded (/etc/systemd/system/ollama.service; enabled; preset: disabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (running) since Fri 2024-08-09 11:13:18 CEST; 6s ago
Main PID: 82811 (ollama)
Tasks: 18 (limit: 18994)
Memory: 1.7G
CPU: 8.917s
CGroup: /system.slice/ollama.service
└─82811 /usr/local/bin/ollama serve$ netstat -nlap|grep 114
…
tcp 0 0 127.0.0.1:11434 0.0.0.0:* LISTEN –
tcp 0 0 127.0.0.1:11435 0.0.0.0:* LISTEN 6638/ollama

Hmm, Zwei Ollama’s … ja klar, eins vom Flatpak und eins haben wir je gerade installiert.

Alpaca Daten übertragen

Weil das Vorbereiten der Modelle und das Pullen der Datenblobs nicht jedermans Sache ist, klauen wir uns jetzt die Daten vom Flatpak und schieben es der eigenen Installation unter 😀 Alpaca beendet man jetzt am besten

$ ls -la .var/app/com.jeffser.Alpaca/data/
insgesamt 24
drwxr-xr-x. 5 marius marius 4096 9. Aug 11:07 .
drwxr-xr-x. 7 marius marius 4096 6. Aug 09:34 ..
drwxr-xr-x. 2 marius marius 4096 7. Aug 15:59 chats
drwx——. 3 marius marius 4096 6. Aug 09:34 .nv
drwxr-xr-x. 3 marius marius 4096 8. Aug 13:35 .ollama
-rw-r–r–. 1 marius marius 280 9. Aug 11:07 tmp.log

 

$ su root
$ systemctl stop ollama
$ mv /usr/share/ollama/.ollama /usr/share/ollama/.ollama.old
$ mv /home/$USER/.var/app/com.jeffser.Alpaca/data/.ollama /usr/share/ollama
$ chown ollama: -R /usr/share/ollama/.ollama
$ systemctl enable -now ollama

Fertig. jetzt könnt Ihr direkt mit den installierten Modellen arbeiten und braucht keine GUI mehr. Das erlaubt unserer Freundin Carola jetzt Ollama direkt auf Port 11434  anzusprechen und Ihre Fähigkeiten zu erweitern 😉

WARNUNG:

Diese Sprachmodelle sind riesig und werden komplett in den Speicher geladen. Unter 16 GB Ram geht da gar nichts, weil Carolas STT Dienst ja auch schon 3,2 GB Ram haben will und die Modelle meisten größer als 5 GB sind.

Wie das alles genau geht, gibt es nächstes Linux am Dienstag 😉

Als kleine Vorschau, was Euch qualitativ so erwartet, wenn Ihr den Kram lokal bei Euch laufen lasst, hier ein Bericht von einem „KI“-Assistenten-Gadget, von dem ich genau weiß, was es getan hat :DDD

Wer dagegen lieber live bei der Zerstörung von „KI“ dabei ist, der ist besser nächste Woche Dienstag um 19 Uhr bei Linux am Dienstag dabei :DDD

Wer mal bewusst gekauftes Sponsering für ein Produkt erleben möchte, der schaut sich zum Rabbit R1 das mal an:

„gekauft“, weil das Teil so schlecht ist, daß das unmöglich nicht aufgefallen sein kann 😉

aktuelle SSH Lücke verpflastern

Posted on by

Updaten ist immer gut wenn Sicherheitslücken geschlossen werden sollen, aber in der Realität kommt es vor, daß Dienste nicht immer (gleich) das Update bekommen, daß Sie benötigen.

aktuelle SSH Lücke verpflastern

Die aktuelle SSH Lücke wirft auf allen möglichen Geräten mit verwundbarer Version ein Problem auf, wenn dieses keine Updates erhält, denn ohne SSH kommt man nicht mehr auf dies Gerät drauf und davon hat keiner was. Solange das Gerät die SSH Schnittstelle ins LAN öffnet, mag ein Nicht-Patchen noch eine kalkulierbare Lösung sein.

Wenn das Gerät aber ins Netz zeigen muß, dann wäre es das Aus, wenn es kein Update gibt, oder gibts da doch was, was man machen könnte?

Das Qualsys Pflaster

Wenn Ihr Nachts um halb eins im Bett von der Lücke gehört hättet, hättet Ihr Euch auch den Qualsys Bericht dazu durchgelesen, der entscheidet dann darüber, ob man sich final hinlegen kann, oder ob eine Nachtschicht eingelegt werden muß.

In dem Bericht stand u.a. drin, daß man ca. 1 Woche hat, bis der Angreifer mit dem Angriff mal Erfolg haben wird. Darauf kann man sich leider nicht ausruhen, weil das nur ein Statistischer Wert ist, der zufällig auch schon beim ersten mal funktionieren kann.

Am Ende stand aber noch etwas anderes, nämlich daß man einfach „LoginGraceTime 0“ setzen kann, dann läuft der Angriff komplett ins Leere, dafür kauft man sich eine Pseudo-DOS Schwachstelle ein, spricht, Angreifer könnten beim rumprobieren die Leitung dicht machen, so daß es schwierig wird ins System einzuloggen. Natürlich ist das immer noch besser, als wenn jeder leidlich lästige Kleinkriminelle auf dem System Rootzugriff haben kann. PS: SSHD Neustart nicht vergessen 😉

Leider habe ich in keinem News- oder Blogbeitrag gelesen, daß es diese Möglichkeit gab.

Fedora hat’s mal wieder verpeilt

Ein bisschen enttäuscht war ich vom zeitlichen Verlauf der Fedora Updates von OpenSSH, denn die platzten mitten in Linux am Dienstag rein,was extrem verstörend war, weil die OpenSSH Patche selbst bereits seit 4 Wochen an die Distributionen übermittelt waren. Die Fedora Maintainer hatten mal wieder völlig verpeilt, ein CritPath Update einer schweren Sicherheitslücke zu verteilen. Nicht zum ersten mal, möchte ich betonen. Da muß man echt hinterher sein manchmal.

Link zur Lücke: CVE-2024-6387

Link zur Quelle: Qualsys Bericht

Recall jetzt im REPO verfügbar

Posted on by

Die neue Version von Recall ist jetzt als RPM verfügbar. Wir haben auch das Fileformat geändert und es global für alles User zur Verfügung gestellt.

Recall jetzt im REPO verfügbar

Wer das Repo noch nicht hat, hier mal nachlesen:

PVA: Carola hat Ihr eigenes Repo bekommen

Die neuen Funktionen von Recall brauchen jetzt nur noch 40% Platz von der ersten Version, weil wir von PNG auf JPG umgestellt haben.

Dazu haben wir noch Recall als systemweiten Timer eingerichtet und für alle User aktiviert, was man natürlich für sich als Benutzer abschalten kann 😉
Wer das für einen Benutzer auf seinem PC machen möchte, der gibt als der Benutzer ein:

systemctl –user disable recall.*

Falls Ihr Euch fragt, wieso es global aktiviert ist: für den Otto-Normal-Benutzer ist es zu schwer zu aktivieren, das bekommen wir nie kommuniziert. Da muß es nach Installation einfach funktionieren.