Menü
  • Startseite
  • Über mich
    • Unterstütze mich
  • Belletristik
  • Fachbücher
    • Selfhosting
  • Podcast
    • Abonnieren
  • Software
  • Kontakt
    • Datenschutzerklärung
    • Impressum

seeseekey.net

Invictus Deus Ex Machina

  • github
  • rss
  • comment
  • twitter
  • youtube

FESS unter Ubuntu installieren

2. Februar 2021 3 Kommentare Tags: Administrator, Apache License, Crawler, Elasticsearch, Embedded, Enterprise, FESS, FOSS, Frontend, GitHub, Installation, Java, Konfiguration, Localhost, Login, Nginx, Oberfläche, Projekt, Reverse Proxy, Search Server, Server, Service, Suche, Suchmaschine, Symbolleiste, systemd, Test, Ubuntu, Unit

Vor ein paar Tagen war ich auf der Suche nach einer lokalen Suchmaschine, mit der ich einen größeren Datenbestand durchsuchen wollte. Fündig geworden bin ich bei FESS, welches sich selbst als Enterprise Search Server beschreibt. Einen solchen wollte ich im Rahmen einer Testinstallation unter Ubuntu aufsetzen. Im ersten Schritt wird dazu der entsprechende Nutzer angelegt und in diesen gewechselt:

adduser --disabled-password --gecos "" fess
su fess
cd

Anschließend wird das aktuelle Release heruntergeladen und entpackt:

wget https://github.com/codelibs/fess/releases/download/fess-13.10.2/fess-13.10.2.zip
unzip fess-13.10.2.zip 
mv fess-13.10.2 fess
rm fess-13.10.2.zip

Danach kann FESS testweise gestartet werden:

cd fess/bin/
./fess

Der Server hört anschließend auf dem Localhost auf Port 8080. Über die entsprechende URL:

http://localhost:8080

kann FESS dann aufgerufen werden. Soll FESS über Nginx als Reverse Proxy angesteuert werden, so muss unter Nginx eine entsprechende Konfiguration für die Seite angelegt werden:

nano /etc/nginx/sites-available/example

In dieser Datei wird nun die Konfiguration hinterlegt:

server {
  listen 443;
  listen [::]:443 default_server;

  ssl on;
  ssl_certificate        /etc/letsencrypt/live/example.org/fullchain.pem;
  ssl_certificate_key    /etc/letsencrypt/live/example.org/privkey.pem;

  server_name example.org;

  location / {
      proxy_pass http://localhost:8080;
  }
}

Nach einem Neustart von Nginx mittels:

service nginx restart

ist der Service über die gewünschte URL erreichbar. FESS arbeitet in Verbindung mit Elasticsearch; für den produktiven Einsatz, sollte eine entsprechende Instanz installiert und für die Zusammenarbeit mit FESS konfiguriert werden. Wird dies nicht getan, läuft FESS mit einer Embedded-Variante von Elasticsearch. Für erste Gehversuche und Tests reicht dies aber völlig aus.

Die Oberfläche von FESS im Entwicklermodus

Soll FESS als Service laufen, muss eine entsprechende systemd-Unit angelegt werden.

nano /etc/systemd/system/fess.service

Diese Unit wird nun wie folgt definiert:

[Unit]
Description=FESS Server
After=network.target

[Service]
Type=simple
User=fess
Group=fess
WorkingDirectory=/home/fess/fess/bin
ExecStart=/home/fess/fess/bin/fess
Restart=always
Environment=USER=fess HOME=/home/fess

[Install]
WantedBy=multi-user.target

Nachdem die Unit gespeichert wurde, kann sie aktiviert und gestartet werden:

systemctl enable fess
systemctl start fess

Über die Oberfläche kann sich als Administrator angemeldet werden. Die Standardzugangsdaten lauten:

Nutzername: admin
Passwort: admin

Nach dem ersten Login müssen diese geändert werden. Für einen ersten Testlauf kann in den Einstellungen unter Crawler -> Web oder Crawler -> Dateisystem ein erstes Ziel definiert werden. Anschließend kann der Vorgang manuell über die Symbolleiste oben rechts gestartet werden. Nachdem der Vorgang abgeschlossen ist, kann über das Frontend von FESS gesucht werden.

Die administrative Oberfläche von FESS

Die offizielle Seite des Projektes ist unter fess.codelibs.org zu finden. Das Projekt ist unter der Apache License lizenziert und damit freie Software.

Nutzer ohne Möglichkeit zum Login erstellen

6. Juli 2019 0 Kommentare Tags: adduser, Befehl, Konsole, Linux, Login, Nutzer, Option, Optionen, su, Terminal, Ubuntu, User

Unter Linux existieren eine Reihe von Nutzern. So nutzt der Nutzer des Systems einen Nutzer und auch viele andere Dienste legen Nutzer an, wie z.B. www-data. Wenn für einen Dienst ein Nutzer angelegt werden soll, so könnte der Nutzer wie folgt angelegt werden:

adduser example

Damit würde ein vollwertiger Nutzer mit einem Passwort erzeugt werden. Soll nun ein Nutzer ohne Passwort erzeugt werden, so muss der adduser-Befehl um eine Option erweitert werden:

adduser --disabled-password example

Damit wird ein Nutzer ohne Passwort angelegt. Trotzdem wäre es noch möglich sich über diesen Nutzer anzumelden. Wenn dies nicht gewünscht ist, kann der Nutzer dementsprechend angelegt werden:

adduser --disabled-login example

Dem Nutzer ist es damit nicht mehr möglich sich einzuloggen. Allerdings kann durchaus mittels su in den Kontext des Nutzers gewechselt werden, z.B. um im Kontext des Nutzers einen Dienst zu installieren.

Der Unterschied zwischen den beiden Optionen ist, dass die Option disabled-password nur das Passwort deaktiviert, aber Logins über ein SSH-Schlüsselpaar zulassen würde. Bei der Option disabled-login ist dies nicht der Fall. Hier ist kein Login mehr möglich. Rückgängig gemacht werden kann die Beschränkung des Nutzers, indem für den Nutzer ein Passwort gesetzt wird.

Authentisierung, Authentifizierung und Autorisierung

28. April 2019 0 Kommentare Tags: Ausweis, Authentifizierung, Authentisierung, Autorisierung, Bedeutung, Begriffe, Identität, IT, Login, Schreiben, Verwechslung

Im technischen Bereich wird des Öfteren von den Begriffen Authentisierung, Authentifizierung und Autorisierung geredet. Das Problem an diesen Begrifflichkeiten ist das sie gerne durcheinander gebracht werden. Doch was bedeuten die Begriffe nun konkret? Fangen wir mit dem Begriff Authentisierung an.

Der Prozess, bei dem eine Person einen Nachweis vorlegt, dass die dargestellte Identität korrekt ist, die Authentisierung. Im IT-Kontext kann dies z.B. durch einen Login mit einem Nutzernamen und einem Passwort bewerkstelligt werden. In der physischen Welt wäre für die Authentisierung z.B. ein Ausweis geeignet. Wenn die von der Person gelieferten Daten wie ein Login oder ein Ausweis geprüft werden, so stellt dies eine Authentifizierung dar.

Authentisierung und Authentifizierung am Beispiel der Kommunikation eines Nutzers mit einem Server

Nachdem die Identität bestätigt wurde, muss im letzten Schritt ermittelt werden, ob die Person die entsprechende Berechtigung besitzt. Dies ist die sogenannte Autorisierung. Erst wenn die Authentisierung, Authentifizierung und Autorisierung erfolgreich durchgeführt wurden, kann die entsprechende Aktion durchgeführt werden.

Unterschiedliche SSH-Schlüssel nutzen

24. Februar 2019 3 Kommentare Tags: FOSS, Kryptografie, Login, Schlüssel, Sicherheit, SSH

Um sich mit einem Rechner per SSH zu verbinden, kann ein Passwort oder ein kryptografisches Schlüsselpaar genutzt werden. Aus Gründen der Sicherheit sollte ein Login über SSH per Passwort im Normalfall nicht möglich sein. Stattdessen sollte sich immer über das Schlüsselpaar identifiziert werden. Dazu wird ein privater und ein öffentlicher Schlüssel generiert. Der öffentliche Schlüssel wird beim Zielserver in der Datei:

.ssh/authorized_keys

hinterlegt. Für die nötigen kryptografischen Operationen wird schließlich der private Schlüssel genutzt, welcher auf dem eigenen Rechner verbleibt. Normalerweise wird so nur ein Schlüsselpaar genutzt. Allerdings kann es durchaus vorkommen, das nicht nur ein Schlüssel, sondern mehrere unterschiedliche Schlüssel für die Verbindung zu unterschiedlichen Servern verwendet werden soll. Diese müssen dann auf dem eigenen Rechner vorgehalten werden. In diesem Fall muss der SSH-Client darüber informiert werden mit welchem Schlüssel die Anmeldung erfolgen soll. Normalerweise würde der Client wie folgt genutzt werden:

ssh root@example.com

In diesem Fall würde der Standardschlüssel aus dem ~/.ssh/-Verzeichnis genutzt werden. Soll nun ein bestimmter Schlüssel genutzt werden so muss der Parameter -i angegeben werden:

ssh -i .ssh/otherkey root@example.org

Damit kann der Schlüssel spezifiziert werden, welcher für die Verbindung genutzt werden soll. Eine andere Möglichkeit ist es für die einzelnen Server eine Konfiguration in der Datei ~/.ssh/config zu hinterlegen.

Host example.com
IdentityFile ~/.ssh/id_rsa

Host example.org
IdentityFile ~/.ssh/otherkey

So können unterschiedliche Schlüssel für unterschiedliche Server genutzt werden.

Systeminfo beim SSH-Login aktivieren

4. Oktober 2013 2 Kommentare Tags: Login, SSH, System, Ubuntu

Wenn man sich auf einem Ubuntu-Server einloggt, bekommt man meist folgende Zeilen zu sehen:

Welcome to Ubuntu 13.04 (GNU/Linux 3.8.0-31-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Thu Oct  3 11:23:01 CEST 2013

  System load:  0.0                Processes:           95
  Usage of /:   71.0% of 969.52GB  Users logged in:     0
  Memory usage: 1%                 IP address for eth0: 192.168.1.50
  Swap usage:   0%

  Graph this data and manage this system at https://landscape.canonical.com/

0 packages can be updated.
0 updates are security updates.

Last login: Sat Sep 28 15:26:35 2013 from localhost

Unter Umständen kann es aber auch passieren das man diese Meldung nicht sieht. Den auszugebenen Text findet man dabei in der Datei “/etc/motd”. Dort kann man das Verhalten beim Login allerdings nicht konfigurieren. Um die Meldung zu aktivieren, muss stattdessen die Datei “/etc/pam.d/login” im Editor angepasst werden. Dort findet man die Zeilen:

# Prints the message of the day upon succesful login.
# (Replaces the `MOTD_FILE' option in login.defs)
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
session    optional   pam_motd.so  motd=/run/motd.dynamic noupdate
session    optional   pam_motd.so

welche je nach Bedarf ein oder auskommentiert werden können. Sind diese Zeilen bereits einkommentiert, so liegt das Problem am Fehlen des Kommandos “landscape-sysinfo”. Sobald das passende Paket “landscape-common” nachinstalliert wurde, funktioniert das Anzeigen der Systeminformationen nach einem Login wieder.

Selfhosting

Selfhosting Selfhosting
Server aufsetzen und betreiben
(Informationen)

Podcast

Der Podcast rund um Technik, Retro, Spiele, Softwareentwicklung, freie Software und weitere Themen aus seeseekeys Welt.

Projekte

Blankensee in Mecklenburg
Nekrologium - Auflistung der von uns gegangenen
Wryte - Werkzeuge für Autoren und Entwickler

OSBN

OSBNDieser Blog ist Mitglied im Open-Source-Blog-Netzwerk. Schau vorbei, wenn dich Open-Source interessiert, oder mache mit, wenn du selbst Blogger bist. Dies sind die zuletzt erschienenen Artikel:

  • LVFS verteilt 25 Mio. Firmware- und BIOS-Versionen von linuxnews.de
  • GhostBSD: Fertiges Desktop-System auf FreeBSD Basis von gnulinux.ch
  • Steam Link App gibt es ab sofort für 64-Bit-Linux – via Flathub von bitblokes.de
  • Pinephone: Daily Driver – Tag 1 von marius.bloggt-in-braunschweig.de
  • Structs und die Strict Aliasing Rule in C von blog.v-gar.de
  • Android ohne Google IX – Mehr Kontrolle mit NetGuard von curius.de
  • musicchris.de auf neuem CMS von musicchris.de
  • NGINX - Webserver, Load Balancer und Proxy von itrig.de
  • Mozilla veröffentlicht Firefox Klar 8.13.1 für Android von soeren-hentzschel.at
  • Der Pudding an der Computerwand von tuxproject.de

Tags

.NET Android App Apple C# Entwicklung FOSS Git GitHub Google GPL GPL3 Invertika iOS Java JavaScript Kunst Kurzfilm Leben Linux macOS Minecraft MIT MMORPG Mono Neubrandenburg OpenMoko PHP Plugin Politik Probleme Projekte Python Server Sicherheit Spiele Terminal Ubuntu Update Video Vimeo Web Windows WordPress YouTube
  • seeseekey.net – Invictus Deus Ex Machina
↑