Konfiguration mit Lsyncd synchronisieren

Hallo!

Heute möchte ich euch ein Tool vorstellen mit dem man relativ einfach, sicher und in nahezu realzeit Konfiguration auf andere Systeme und umgekehrt synchronisieren kann. Das Tool hoert auf den Namen Live Syncing (Mirror) Daemon, oder kurz gefasst Lsyncd.

Als erstes möchte ich etwas auf die Magie von Lsyncd eingehen, damit man einen Eindruck bekommt wie das Tool arbeitet und was für Möglichkeiten sich ergeben. Lsyncd verwendet unter Linux inotify und unter MacOS FSEvents um Änderungen am Verzeichnissbaum zu beobachten. Anhand dieses “Monitorings” kann Lsyncd feststellen, ob Änderungen im zur synchronisation bestimmten Verzeichnis passiert sind. Ist dies der Fall, startet Lsyncd die synchronisation mit den zuvor entsprechend gesetzten Parametern. Die Parameter sind z.B. welches Verzeichniss von soll wohin repliziert werden und welches Protokoll soll dafür genutzt werden z.B. rsync.

Kommen wir zum interessanteren Teil die Installation und Konfiguration von Lsyncd. In den meisten Distributionen ist Lsyncd bereits als fertiges Paket vorzufinden. Für die demonstration verwende ich eine CentOS 7.x Maschine in VirtualBox auf einem Laptop.

Vorbereitung/Installation (CentOS 7.x)

Zunächst installieren wir das lsyncd Paket mittels YUM und generieren bzw. verteilen anschließend unseren SSH-Key den wir später für Lsyncd nutzen.

[root@lsyncdemo ~]# yum install lsyncd
[root@lsyncdemo ~]# ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/root/.ssh/id_ed25519): /root/.ssh/id_lsync
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_lsyync.
Your public key has been saved in /root/.ssh/id_lsyync.pub.
The key fingerprint is:
SHA256:ntsHfyqPkwffQ3IPMUkZ6kIOMdSBqVhREwgag7V1TgI root@lsyncdemo
The key's randomart image is:
+--[ED25519 256]--+
| oE.+.+=B=.. .o |
|. * =o o+. .o |
| o o... . .. . |
| . . + . + |
| S o . o |
| . .o.. + |
| o * = o |
| o+.= + .|
| . o*oo . |
+----[SHA256]-----+
[root@lsyncdemo ~]# ssh-copy-id -i /root/.ssh/id_lsync i2node01

Konfiguration

Nun kommen wir zur Konfiguration unseres Lsyncd, hierfür existiert genau eine Konfigurationsdatei unter /etc/ (equivalenter pfad osx) mit dem Namen lsyncd.conf. Für unser Beispiel synchronisiere ich Verzeichnis mit Konfiguration auf meinen Icinga2 Master (i2node01).

[root@lsyncdemo ~]# vi /etc/lsyncd.conf
<...
- sync{default.rsyncssh, source="/var/www/html", host="localhost", targetdir="/tmp/htmlcopy/"} //Beispiel Konfiguration entfernen

+ sync{ //Icinga Configuration
+  default.rsync, //Wir nutzen rsync zum Synchronisieren
+  source="/home/mdeparade/icinga2/scripts", //Das Quellverzeichnis
+  target="i2node01:/etc/icinga2/scripts", //Das Zielverzeichnis
+  rsync={rsh ="/usr/bin/ssh -l root -i /root/.ssh/id_lsync", owner = true, perms = true,}
+ }
...>

Kurze Erläuterung: Die letzte Zeile unserer Konfiguration gibt rsync noch ein paar Informationen mit: Wir bauen einen SSH-Tunnel als Benutzer root auf, mit dem SSH-Key “id_lsync”, anschließend sagen wir noch das alle Berechtigungen der Dateien/Verzeichnisse erhalten bleiben sollen.

Abschluss

Nachdem wir Lsyncd mit Konfiguration versorgt haben, können wir diesen direkt starten und Überprüfen ob unser Synchronisation auch ordnungsgemaess funktioniert:

[root@lsyncdemo ~]# cat /etc/lsyncd.conf
----
-- User configuration file for lsyncd.
--
-- Simple example for default rsync, but executing moves through on the target.
--
-- For more examples, see /usr/share/doc/lsyncd*/examples/
--
sync{
default.rsync,
source="/home/mdeparade/icinga2/scripts",
target="i2node01:/etc/icinga2/scripts",
rsync={rsh ="/usr/bin/ssh -l root -i /root/.ssh/id_lsync", owner = true, perms = true,} 
}
[root@lsyncdemo ~]# systemctl enable lsyncd --now
[root@lsyncdemo ~]# systemctl status lsyncd
● lsyncd.service - Live Syncing (Mirror) Daemon
 Loaded: loaded (/usr/lib/systemd/system/lsyncd.service; enabled; vendor preset: disabled)
 Active: active (running) since Fri 2018-04-09 10:49:36 BST; 1s ago
 Main PID: 1477 (lsyncd)
 CGroup: /system.slice/lsyncd.service
 └─1477 /usr/bin/lsyncd -nodaemon /etc/lsyncd.conf

Apr 09 10:49:36 lsyncdemo systemd[1]: Started Live Syncing (Mirror) Daemon.
Apr 09 10:49:36 lsyncdemo systemd[1]: Starting Live Syncing (Mirror) Daemon...
[root@lsyncdemo ~]# ll /home/mdeparade/icinga2/scripts
total 4
-rw-r--r--. 1 root root 5 Apr 09 10:52 test.conf
[root@lsyncdemo ~]# ssh -i /root/.ssh/id_lsync -l root 192.168.56.11 ls /etc/icinga2/scripts
test.conf
[root@lsyncdemo ~]# exit
logout
Connection to blog.netways.de closed.

Eindrücke aus Bayern: Die Alpen

Max Deparade

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.

A personal Linux backup solution

Having personal backups is a must, but what can you do if you don’t have a mac that runs timemachine?

My first instinct was using the tool of choice of a friend: duplicity. It’s free software, does encryption and incremental backups, what more could you want? But duplicity does not offer a very user experience. The docs are work in progress, the –help is a bit of a mess and the man page is too verbose for a quick start. Obviously I have little problem reading and learning before using a tool, which is why I gave up and looked for a different one.

Restic does all what I want and duplicity can, but it has a good documentation, bash completion and other optional bonuses for making usage and, in turn, my life much easier.  It makes sense to think about what to backup before thinking about the right tool. I only want to backup from ~, I don’t care about `/etc` or other places with config or data, it would be no use to me when someone was to throw this laptop down a bridge. So just how much is lying around in my home directory?

$ du -h -d1 /home/jflach | grep "G" 
1.9G	/home/jflach/i2
4.3G	/home/jflach/.ccache
20G	/home/jflach/git
108G	/home/jflach/vmware
6.6G	/home/jflach/.cache
20G	/home/jflach/Documents
1.2G	/home/jflach/.thunderbird
3.3G	/home/jflach/Downloads
5.6G	/home/jflach/.vagrant.d
171G	/home/jflach

Luckily I have no folder with an upper case “G” in the name and I can see that over 50% are used up by vmare/. I don’t really need to backup my virtual machines, it’d be annoying to lose them but no reason to panic. `.ccache/`, `.cache/` and `Downloads` are completely irrelevant, bringing the total down to just above 50GB.

Back to restic. Creating a new local backup repository is easy:

$ restic init --repo /tmp/backup                                                                                                    
enter password for new backend: 
enter password again: 
created restic backend 929fc4f740 at /tmp/backup

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

Now the for the actual backup, I have a file containing the excluded directories:

$ cat ~/.config/restic.exclude
Downloads
vmware
.ccache
.cache

And the command is simply:

$ restic -r /tmp/backup backup ~ --exclude-file=.config/restic.exclude
enter password for repository: 
password is correct
scan [/home/jflach]
scanned 10123 directories, 64039 files in 0:00
[11:07] 100.00%  76.166 MiB/s  49.612 GiB / 49.612 GiB  74162 / 74162 items  0 errors  ETA 0:00 
duration: 11:07, 76.12MiB/s
snapshot dd45c515 saved

It took eleven minutes on my machine to encrypt and compress about 50GiB of data. Restic starts a few threads and voraciously consumes CPU time and memory as it runs. Get yourself a fresh cup of coffee, working is no fun while the tool runs.

All that’s now left to do is to copy the directory to some external server or hard drive. Restic offers support for common sync tools like sftp, google cloud or rclone, whatever you use it will be your job to automate and define its behavior.

Jean Flach

Autor: Jean Flach

Geboren und aufgewachsen in Bamberg, kam Jean (das "-Marcel" ist still) nach einem Ausflug an die Uni, als Azubi zu NETWAYS. Dort sitzt er seit 2014 im Icinga 2 core Entwicklungsteam.

Icinga Web 2 – todsicher.

Nachdem ich mich zuletzt in den Sänften Apples ausgeruht habe, geht es heute zurück ans eingemachte – oder besser gesagt: Back to the Roots! Selbst als alter Icinga Web 2– und Modulentwickler habe ich noch längst nicht alle Vorzüge dieses Feldes beansprucht.

Einer davon ist die Möglichkeit, alles Mögliche für die Authentifizierung herzunehmen. Einzige Voraussetzung: der Webserver muss mitspielen. Manche Authentifizierungsverfahren gelten als sicher, andere nur wenn das Passwort weise gewählt ist… aber zumindest eines ist todsicher: TLS (aka “SSL”) Client-Zertifikate. Die Vorteile liegen auf der Hand:

  • mit der folgenden Anleitung relativ einfach umzusetzen
  • Erstellung unsicherer Zertifikate (analog zu den Passwörtern) nicht möglich
  • keine geheimen/privaten Schlüssel werden während der Authentifizierung übertragen (kann man von Passwörtern nicht behaupten)
  • Unbefugte werden schon vom Webserver “abgefangen” und kommen gar nicht erst an Icinga Web 2 heran

Na dann riegeln wir mal ab…

Zertifikate erstellen

Sowohl der Webserver als auch jeder Client brauchen je ein TLS-Zertifikat, das von einer der Gegenseite vertrauenswürdigen Zertifizierungsstelle (CA) unterschrieben ist. Diese Unterschriften könnte ich einkaufen oder kostenlos beziehen, aber der Einfachheit halber erstelle ich mir für beide Seiten je eine CA und unterschreibe je ein Zertifikat.

Die Sänfte Apples bieten in der Schlüsselbundverwaltung einen Zertifikatsassistenten, aber auch der eingefleischte Linux-Sysadmin hat mit Openssl ein Umfangreiches Bordmittel zur Verfügung.

Server

Im Gegensatz zum Client müssen Nutzer beider Betriebssysteme darauf achten, dass das Server-Zertifikat über einen sog. “subjectAltName” verfügt. Sonst staunt man beim Aufbau der Umgebung nicht schlecht: Trotz Vertrauen in die CA und passendem commonName erkennt zumind. Google Chrome das Zertifikat nicht an.

Die hervorgehobenen Stellen müssen höchst wahrscheinlich an die eigene Umgebung angepasst werden – z.B. eine Domäne statt einer IP Adresse und damit auch CN_KIND=DNS.

openssl req -x509 -newkey rsa:4096 -subj '/CN=example com CA - server' -md5 -keyout ca-server.key -out ca-server.crt -nodes

CN_KIND=IP ; CN=172.28.128.3

openssl req -newkey rsa:4096 -subj "/CN=$CN" -keyout server.key -out server.csr -nodes

openssl x509 -req -in server.csr -sha512 -out server.crt -CA ca-server.crt -CAkey ca-server.key -CAcreateserial -extensions SAN -extfile <(printf '[SAN]\nsubjectAltName=%s:%s' "$CN_KIND" "$CN")

Client

Bis auf den hier nicht nötigen “subjectAltName” – das gleiche in grün.

openssl req -x509 -newkey rsa:4096 -subj '/CN=example com CA - client' -md5 -keyout ca-client.key -out ca-client.crt -nodes

openssl req -newkey rsa:4096 -subj '/CN=Alexander Klimov' -keyout client.key -out client.csr -nodes

openssl x509 -req -in client.csr -sha512 -out client.crt -CA ca-client.crt -CAkey ca-client.key -CAcreateserial

Kleines Easter-Egg am Rande: Es spielt keine Rolle, ob ein Root-CA-Zertifikat mit SHA512, MD5 oder handschriftlich signiert wurde, da es nur auf dessen Vorhandensein im eigenen Schlüsselbund ankommt.

Zertifikate importieren

Ein nicht offizielles Server-CA-Zertifikat und das eigene Client-Zertifikat muss natürlich in den Browser importiert werden. Dafür ist ein kleiner Zwischenschritt nötig:

alexanders-mbp:debian aklimov$ openssl pkcs12 -in client.crt -inkey client.key -export -out client.p12
Enter Export Password:
Verifying - Enter Export Password:
alexanders-mbp:debian aklimov$

“client.p12” (und evtl. “ca-server.crt”) kann anschließend in den Browser importiert werden. Leider ist ein temporäres Passwort unumgänglich, aber “123456” o.ä. geht auch.

Wer diesen Schritt verschleppt, fällt bei der Einrichtung von Icinga Web 2 auf die Nase: Entweder beschwert sich der Browser über eine “nicht sichere” Verbindung oder der Webserver weist die Verbindung ab.

Icinga Web 2 installieren

DIST=$(awk -F"[)(]+" '/VERSION=/ {print $2}' /etc/os-release); \
echo "deb http://packages.icinga.com/debian icinga-${DIST} main" >  /etc/apt/sources.list.d/${DIST}-icinga.list; \
echo "deb-src http://packages.icinga.com/debian icinga-${DIST} main" >>  /etc/apt/sources.list.d/${DIST}-icinga.list

wget -qO - https://packages.icinga.com/icinga.key | apt-key add -
apt update
apt install icingaweb2 -y

cp /vagrant/server.crt /etc/ssl/certs/todsicher.pem
cp /vagrant/server.key /etc/ssl/private/todsicher.pem
cp /vagrant/ca-client.crt /etc/ssl/certs/todsicher-ca.pem

a2dissite 000-default.conf
a2enmod ssl
a2enmod headers
vim /etc/apache2/sites-available/todsicher.conf
a2ensite todsicher.conf
service apache2 restart

Nachdem das Icinga-Repository hinzugefügt wurde, kann auch schon das Paket “icingaweb2” installiert werden. Dieses bringt den Apache-Webserver mit und integriert sich entsprechend. Darauf hin müssen die Zertifikate installiert und deren Verwendung konfiguriert werden.

/etc/apache2/sites-available/todsicher.conf

<VirtualHost *:80>
	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	RewriteEngine On
	RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

<VirtualHost *:443>
	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	SSLEngine on
	SSLCertificateFile /etc/ssl/certs/todsicher.pem
	SSLCertificateKeyFile /etc/ssl/private/todsicher.pem
	Header always set Strict-Transport-Security "max-age=2678400"

	SSLCACertificateFile /etc/ssl/certs/todsicher-ca.pem
	SSLVerifyClient require
	SSLVerifyDepth 1
	SSLUserName SSL_CLIENT_S_DN_CN
</VirtualHost>

Sollte jemand auf die Idee kommen, den Server mit HTTP anzusprechen, wird er bedingungslos auf HTTPS umgeleitet – und diese Tat auch nicht wiederholen.

Außerdem wird ein TLS-Client-Zertifikat verlangt, das von entsprechender CA unterschrieben sein muss. Dessen commonName wird im Erfolgsfall als Nutzername behandelt – und genau auf diesen Zug springt Icinga Web 2 auf…

Icinga Web 2 einrichten

Nun greift man via Browser auf Icinga Web 2 zu und richtet es wie gewohnt ein… naja, fast wie gewohnt…

Nachdem der Browser nach dem zu verwendenden Client-Zertifikat gefragt hat, grüßt die Anmeldemaske, die auf den Einrichtungsassistenten verweist. Dieser fordert wie zu erwarten den Einrichtungstoken. Nach dessen Eingabe habe ich ausnahmsweise sämtliche Module deaktiviert, da… dieser Blogpost eh schon viel zu lang ist. (Aber nur die Ruhe, wir haben’s schon fast.)

Nach einer kleinen Anpassung der PHP-Konfiguration und einem darauf folgenden Neustart des Webservers…

root@contrib-stretch:~# perl -pi -e 's~^;date\.timezone =.*?$~date.timezone = Europe/Berlin~' /etc/php/7.0/apache2/php.ini
root@contrib-stretch:~# service apache2 restart

… bestätigt auch schon die erste Ausnahme die Regel: Der Typ des Authentifizierungs-Backends ist auf “Extern” zu setzen, da dies der Webserver übernimmt. Die folgenden Einstellungen des Backends können bei dem voreingetragenen belassen werden. Wenn alles richtig konfiguriert wurde, schlägt der Assistent den bedienenden Benutzer als Administrator vor. Ab da bleiben nur noch die Formalitäten…

Fazit

Wer auf das Monitoring-System Zugriff hat, hat viel Macht.

Bernd Erk, NETWAYS CEO

Tja Bernd, auf mein Monitoring-System hat kein Unbefugter mehr Zugriff – todsicher.

Alexander Klimov

Autor: Alexander Klimov

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.

Serverwartung für Kollegen

This entry is part 15 of 16 in the series Azubis erzählen

Philipp und ich haben diese Woche das Vergnügen mit zwei Servern eines Kollegen bekommen. Unsere Aufgabe war im grunde ganz einfach.

Zu machen war:
– Server ausbauen
– Reset iLO Board + neues Passwort vergeben
– Lizenz für iLO Board einspielen
– Upgrade iLO Firmware
– Upgrade Bios
– Upgrade RAID-Controller
– RAID 1 aus 2x 146 GB SAS Festplatten bauen
– RAID 5 aus 3x 5TB SATA Festplatten bauen
– Quad-Port Netzwerkkarte ausbauen
– 10 GBit Netzwerkkarten einbauen
– Debian Minimalinstallation
– Netzwerkkonfiguration für externes Netzwerkinterface (1 GBit)
– Netzwerkkonfiguration für internes Netzwerkinterface (10 GBit)
– Server einbauen

Ich dachte nicht, dass es einfach wird, aber auch nicht, dass es so Zeitintensiv wird. Nachdem wir die Server dann ausgebaut auf dem Tisch liegen hatten, schlossen wir unsere Monitore und Tastaturen an. Als wir dann den Strom anschalteten, ging der Server in den Standby-Leerlauf. In diesem ‘Modus’ liefen die Lüfter schon langsam an. Zuerst war ich überrascht. Einer von diesen Servern ist, im Standby, schon so laut wie mein Gaming-PC, wenn er unter Volllast läuft.

Nun war es an der Zeit uns mal die Software genauer anzuschauen. Wir mussten rausfinden, auf welcher Version das BIOS, das iLO und der RAID-Controller momentan laufen. Nachdem wir das herausgefunden hatten, suchten wir nach den passenden Updates im Internet. Wie wir es gewohnt waren, haben wir mit unserer Suche nach Updates, bei der Herstellerseite angefangen. Wer sich jetzt denkt, “Modellnummer oder Modellbezeichnung suchen und Downloaden”, liegt hiermit allerdings falsch. Wir haben etwa drei Stunden damit verbracht, herauszufinden welches vorgeschlagene Update denn nun das richtige ist und wie man dieses dann Einspielen muss. Die Größe der Updatedatei, belief sich auf sieben Megabyte. Für uns waren normale Updategrößen irgendwo zwischen 500 Megabyte und 1,5 Gigabyte, weswegen wir auch unter großer Verwunderung die heruntergeladene Updatedatei mehrmals überprüften. Nachdem uns unser Ausbilder mitteilte, dass der Server nur noch als “lauter Türstopper” benutzt werden kann, wenn man eine falsche Firmware-Version installiert, bekamen wir nochmehr Angst etwas kaputt zu machen. Bei einer weiteren Überprüfung stellten wir dann fest, dass die Datei, ein einfaches Shell-Script war. Mit einem USB-Stick haben wir dann innerhalb von Sekunden die Updates installiert.

Nachdem wir dann die Firmware-Updates fertiggestellt hatten, galt es die Hardwareteile einzubauen. Wir sollten sechs 5TB HDD Platten und zwei 10 GBit Netzwerkkarten einbauen. Zusätzlich sollten wir auch die vorhandene Quad-Port Netzwerkkarte ausbauen. Philipp schrieb die Seriennummer der einzubauenden HDD Platten auf und ich baute diese dann letztendlich ein.

Jetzt stand noch die iLO Lizenz aktivierung und die RAID-Controller konfiguration an. Das alles ließ sich ganz einfach beim Boot einstellen. Während wir diese Einstellungen vornahmen, hat uns unser Ausbilder noch erklärt was RAID ist und was man damit machen kann. Nun da wir die nötigen Einstellungen vorgenommen hatten, mussten wir nur noch eine Debian 9 Minimalinstallation durchführen und die Netzwerkkarten konfigurieren. Die OS installation war total schnell fertig. Für die Konfiguration der Netzwerkkarten, haben wir in der Konfigurationsdatei (/etc/network/interfaces) die Netzwerkkarte eingetragen und eine statische IP-Adresse vergeben.

Das Projekt hat mir sehr viel Spaß gemacht. Ich freue mich schon sehr darauf, mal wieder mit der Hardware arbeiten zu dürfen.

Killian Pieper-Müller

Autor: Killian Pieper-Müller

Killian ist seit 1. September 2017 bei uns als angehender Fachinformatiker für Systemintegration. Er erwartet sich von seiner Ausbildung richtige Kenntnisse im Programmieren und in Linux. In seiner Freizeit schaut er sehr gerne Serien, Programmiert oder trifft sich mit Freunden ... im Internet zum Online-Gaming.

Konfiguration des Proxyserver Squid mit SquidGuard und Authenifizierung


Ich werde heute beschreiben wie man den Proxy-Server Squid mit SquidGard einrichtet und Zugriff per Benutzer-Authentifizierung.
Anlass ist, das ich selbst bei mir zuhause diese Kombination einsetze, um meinen Kindern manche nicht kinderfreundlichen Inhalte im Web zu ersparen und zu blocken.
Es gibt verschiedene Einsatz-Scenarien von Squid z.B als Caching von Webseiten zum schnellen Anzeigen im Browser.
Zuerst muss man die Pakete dafür installieren, bei mir im Fall von openSUSE-Leap. Pakete können sich bei anderen Linux Distributionen unterscheiden.
zypper in squid squidGuard
Anschließend den Proxyserver Squid beim Systemstart aktivieren:
systemctl enable squid.service
Starten von Squid
systemctl start squid.service
Bei der fertigen Umgebung wird Squid die Anfragen über den SquidGuard leiten, zum die URL’s oder Domains zu überprüfen, ob derjenige Benutzer die Inhalte sehen darf oder nicht.

Als erstes konfiguriere ich den Squid, Konfigurationsdatei liegt unter:

cd /etc/squid/ && vim squid.confz.B meine squid.conf
auth_param basic program /usr/sbin/basic_pam_auth #----> Wichtig Authentifizierung von Usern, wird per Popup erscheinen
auth_param basic children 5 startup=0 idle=1
auth_param basic realm Squid proxy-caching web server
acl localnet src 192.168.100.0/24 # RFC1918 possible internal network #----> Wichtig Zugriff Regel für das Netz von Squid
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
acl password proxy_auth REQUIRED
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localnet password
http_access allow localhost
http_access deny all
http_port 3145
coredump_dir /var/cache/squid
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
err_page_stylesheet /etc/squid/errorpage.css
redirect_program /usr/sbin/squidGuard -c /etc/squidguard.conf #-----> Wichig weiterleitung über SquidGuard und liest Konfig von squid ein
redirect_children 5 #----> Wieviele Kindprozesse darf Squidguard öffnen.

Es wird in dieser Konfig-Datei vieles per Kommentar erklärt, hier empfiehlt sich es mal gelesen zu haben.

Dann müssen noch Berechtigungen der Datei
/usr/sbin/basic_pam_auth
gesetzt werden, damit die Authentifizierung über die angelegten Benutzer funktioniert:
chgroup shadow /usr/sbin/basic_pam_auth
chmod g+s /usr/sbin/basic_pam_auth

Damit alles aktiv geschaltet wird müssen wird den Proxyserver neustarten:
systemctl restart squid.service

So jetzt damit kommen wir zum SquidGuard:
Die Konfigurationsdatei heisst:
vim /etc/squidguard.conf;
Ein Beispiel von mir:
logdir /var/log/squidGuard
dbhome /var/lib/squidGuard/db
src parents {
ip 192.168.100.0/24 # range 192.168.10.0 - 192.168.10.255
# AND
user papa mama # ident Papa und Mama
}
src kids {
ip 192.168.10.17 # Notebook Kind 1
user username # ident Kind1
# AND
ip 192.168.10.14 # Notebook Kind 2
user username (Kind # ident Kind2
}
dest blacklist {
domainlist blacklist/domains
urllist blacklist/urls
}
#####
#
# Zeitregeln
#####
# abbrev for weekdays:
s = sun, m = mon, t =tue, w = wed, h = thu, f = fri, a = sat
time tagsueber {
weekly mtwhfas 12:00-16:00 # Unter der Woche
}
acl {
parents {
pass all
}
kids {
pass !blacklist all
}
default {
pass none
redirect http://hostname/cgi-bin/squidGuard.cgi/blocked?clientaddr=%a&clientname=%n&clientuser=%i&clientgroup=%s&url=%u

Die Datei ist eigentlich sehr einfach strukturiert und auf der Webseite von SquidGuard gut erklärt, deswegen verlinke ich hier gern:
http://www.squidguard.org/Doc/configure.html

Für das Blocken von nicht kinderfreundlichen Seiten gibt es schon fertige Listen, die das meiste auch schon abdecken:
Block-Listen
Diese Listen müssen entpackt und in das Verzeichnis:
cd /var/lib/squidGuard/db/blacklist/
kopiert werden und anschließend initialisiert werden:
squidGuard -C all

So, jetzt sollte alles soweit funktionieren, testen kann man am besten, in dem man mit einem Benutzer, der für das Blocken eingerichtet ist, geblockte URL’s oder Domains aufzurufen, um zu sehen ob diese Seite aufgerufen werden kann.

In diesem Sinne Have Fun!

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

Systemd-Unitfiles und Multi-Instanz-Setups

Tux

Vor einer Weile hab ich bereits eine kurze Erklärung zu Systemd-Unitfiles geschrieben, diesmal will ich auf das Multi-Instanz-Feature von Systemd eingehen, da auch dieses anscheinend nicht jedem bekannt ist.

Als Beispiel soll mir diesmal Graphite bzw. genauer gesagt die Python-Implementierung carbon-cache dienen. Diese skaliert nicht automatisch, sondern erfordert, dass man weitere Instanzen des Dienstes auf anderen Ports startet. Die Konfiguration auf Seiten des carbon-cache ist hierbei recht simpel, denn es wird in einer Ini-Datei nur eine neue Sektion mit den zu überschreibenden Werten geschrieben. Der Sektions-Name gibt hierbei der Instanz den Namen vor. Das ganze sieht dann beispielsweise für Instanz b so aus.

[cache:b]
LINE_RECEIVER_PORT = 2013
UDP_RECEIVER_PORT = 2013
PICKLE_RECEIVER_PORT = 2014
LINE_RECEIVER_PORT = 7102

Mit SystemV hätte man nun das Startskript für jede Instanz kopieren und anpassen müssen, da das mitgelieferte Unitfile leider das Multi-Instanz-Feature nicht nutzt muss ich dies zwar auch einmal tun, aber immerhin nur einmal. Hierbei ist es sinnvoll den Namen zu verändern, um nicht mit dem bestehen in Konflikt zu kommen, wenn man möchte kann man es aber auch durch Verwendung des gleichen Namens “überschreiben”. Für das Multi-Instanz-Feature muss nur ein @ an das Ende des Namens. Baut man nun an entsprechenden Stellen den Platzhalter %i ist auch schon das Multi-Instanz-Setup fertig und man kann einen Dienst mit name@instanz.service starten. In meinem Beispiel wäre dies carbon-cache-instance@b.service mit folgendem Unitfile unter /etc/systemd/system/carbon-cache-instance@.service.

[Unit]
Description=Graphite Carbon Cache Instance %i
After=network.target
 
[Service]
Type=forking
StandardOutput=syslog
StandardError=syslog
ExecStart=/usr/bin/carbon-cache --config=/etc/carbon/carbon.conf --pidfile=/var/run/carbon-cache-%i.pid --logdir=/var/log/carbon/ --instance=%i start
ExecReload=/bin/kill -USR1 $MAINPID
PIDFile=/var/run/carbon-cache-%i.pid
 
[Install]
WantedBy=multi-user.target

Ich hoffe diese kurze Erklärung hilft dem ein oder anderen und ich würde mich freuen zukünftig mehr Dienste, die auf Instanzierung ausgelegt sind, bereits mit einem entsprechenden Unitfile ausgeliefert zu sehen.

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.