Wer das Handling von Tätigkeiten mit Administratorenrechten (“Root”) wie ich aus der Debian-Welt gewohnt ist, wird mit openSUSE zu Anfang so seine Schwierigkeiten haben. Mit zwei Benutzern geht es noch, da man ja das selbe Passwort sowohl für den User als auch für Root einstellen kann. Aber spätestens bei mehr Nutzerkonten ist damit schon Schluss, außer man gibt das Root-Passwort an alle weiter. Beide Lösungen sind sicher irgendwie praktikabel, aber schön ist das alles nicht. Vor allem weil ja eigentlich sudo installiert wäre – aber nur so halbgar genutzt wird.

Also habe ich mal bei meiner aktuellen openSUSE Tumbleweed daran gemacht, dem System ein vernünftiges sudo-Konzept beizubringen und dieses dann auch für YaST anzuwenden. Das war etwas fieselig herauszufinden, hat am Ende aber gut funktioniert.

Los geht’s!

visudo

Standardmäßig fragt sudo nach dem Root-Passwort. Das ist ziemlich unsinnig, also ändern wir es!

1. Im ersten Teil arbeiten wir noch als normaler Benutzer. Die Zeilenangaben können abweichen, je nach Alter der Datei/Systemversion und vorherigen Änderungen daran.
   

   sudo visudo

2. Die Parameter in Zeile 43 beginnend mit env_keep = “LANG… ergänzt du am Ende innerhalb der Anführungszeichen mit:
   

   DISPLAY XAUTHORITY

3. Die Zeilen 68 und 69 kommentierst du komplett aus, damit nicht mehr das Passwort des “Zielusers” abgefragt wird:
   

   #Defaults       targetpw
   #ALL    ALL = (ALL) ALL

4. Zusätzlich kommentierst du Zeile 81 ein, löschst also das Kommentarzeichen # weg:
   

   %wheel ALL=(ALL) ALL

5. Speichern, schließen und dann deine(n) Benutzer entweder über YaST oder direkt im Terminal der Gruppe “wheel” hinzufügen:
   

   gpasswd -a <dein-username> wheel

   Durch Aus- und wieder Einloggen wird die Änderung dann auch übernommen und sudo möchte ab sofort im Terminal immer dein Benutzerpasswort haben.

YaST

Für die grafische Version von YaST wird PolicyKit zur Authentifizierung genutzt, hier ist noch etwas mehr Arbeit nötig. Ab hier arbeitest du als root, wechsle also mit su – den Account.

1. Erstelle eine PolicyKit Action für YaST
   

   vim /usr/share/polkit-1/actions/org.opensuse.pkexec.yast2.policy

2. Folgenden XML-Block fügst du in die Datei ein. Achte dabei bitte auf Zeilenumbrüche beim Kopieren/Einfügen.
   

   <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" "http://www.freedesktop.org/software/polkit/policyconfig-1.dtd">
   <policyconfig>
   
     <action id="org.opensuse.pkexec.yast2">
       <message>Authentication is required to run YaST2</message>
       <icon_name>yast2</icon_name>
       <defaults>
         <allow_any>auth_self</allow_any>
         <allow_inactive>auth_self</allow_inactive>
         <allow_active>auth_self</allow_active>
       </defaults>
       <annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/yast2</annotate>
       <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
     </action>
   
   </policyconfig>

   Speichern, schließen – der Erfolg lässt sich als regulärer Benutzer mit pkexec /usr/sbin/yast2 überprüfen.

3. Die vorgegebene Rechte-Konfiguration sicherst du und ersetzt sie durch die System-Konfiguration. Unsere Datei wird bei einem Upgrade übrigens nicht überschrieben.
   

   mv /etc/polkit-default-privs.local /etc/polkit-default-privs.local.bkup
   cp /etc/polkit-default-privs.standard /etc/polkit-default-privs.local

   Die nötige Anpassung ist überall auth_admin durch auth_self zu ersetzen. Du kannst das auch von Hand machen, mit sed geht das aber bequemer und schneller:
   

   sed -i 's/auth_admin/auth_self/g' /etc/polkit-default-privs.local

4. Damit die Authentifizierung über PolicyKit auch funktioniert, erstellst du ein kurzes Shellscript das künftig als Umweg aus dem Menü aufgerufen wird:
   

   vim /usr/local/sbin/yast2_polkit

5. Das Script sieht wie folgt aus, einfach in die Datei yast2_polkit einfügen:
   

   #!/bin/bash
   
   if [ $(which pkexec) ]; then
           pkexec --disable-internal-agent "/usr/sbin/yast2" "$@"
   else
           /usr/sbin/yast2 "$@"
   fi

6. Speichern und schließen. Abschließend machst du das Script noch ausführbar:

   chmod +x /usr/local/sbin/yast2_polkit

7. Als letztes erstellst du eine .desktop Datei. Damit erscheint der modifizierte YaST-Starter direkt im Hauptmenü und das systemweit für alle Benutzer. Beispielsweise wird er bei Xfce unter “Einstellungen” gelistet. Andere Desktops habe ich nicht getestet, gehe aber davon aus dass der Starter an einer sinnvollen Stelle landet da er ja nur eine angepasste Kopie des Originals ist.
   Natürlich könntest du auch die originale Datei für YaST (YaST.desktop) bearbeiten aber die wird bei einem Upgrade überschrieben. Und eine Kopie in /usr/local/share/applications ignorieren sowohl das Anwendungs- als auch das Whiskermenü.
   Also:
   

   vim /usr/share/applications/YaST2.desktop

8. Einfügen und speichern:
   

   [Desktop Entry]
   X-SuSE-translate=true
   Type=Application
   Categories=Settings;System;X-SuSE-Core-System;X-SuSE-ControlCenter-System;X-GNOME-SystemSettings;
   Name=YaST2
   Icon=yast
   GenericName=Administrator Settings
   Exec=/usr/local/sbin/yast2_polkit
   Encoding=UTF-8
   Comment=Manage system-wide settings
   Comment[DE]=Systemweite administrative Einstellungen
   NoDisplay=false

Das ist alles. Damit ist ein Login als Root nicht mehr nötig bzw. kann bequem über sudo su – mit deinem Benutzerpasswort erfolgen. Ob das Konzept von openSUSE jetzt schlechter oder besser ist, mag ich nicht entscheiden. Das ist Geschmackssache, denke ich.
Was mir auf jeden Fall gut gefallen hat, ist die klare Einhaltung von Standards. Das macht die Suche nach Lösungen deutlich leichter und schneller. Ich konnte dank guter Dokumentation und hilfreichen Forenbeiträgen alles innerhalb von rund einer Stunde fertigstellen – und das große Kenntnisse von PolicyKit!

Eigentlich ist es ja gewünscht wenn das System einem regelmäßig die temporären Dateien wegräumt. Löscht es einem dabei aber auch Dateien welche man gerade erst dort abgelegt hatte, dann steht wohl irgendwas in der Konfiguration schief.

Ich nutze tatsächlich häufig das Verzeichnis /tmp. Gerade beim Schreiben kleiner Skripte ist es ganz angenehm sich im Fehlerfall einfach darauf zu verlassen, dass übrig gebliebene temporäre Dateien schon wieder verschwinden werden. Auch meine virtuellen Python-Umgebungen lege ich, seit mich Holger Peters mal auf diese Idee gebracht hat, stets dort ab. Seit einiger Zeit löschte mir meine openSUSE meine gerade angelegten Dateien aber immer kurz nach dem Systemstart unter der Nase weg.

Da das Problem immer kurz nach dem Systemstart auftrat war schnell klar, dass da wohl der Aufräumcronjob schuld sein muss. Auch wenn dies natürlich inzwischen gar kein Cronjob mehr ist sondern ein Systemd-Timer.

marix@eddie:~> systemctl list-timers
NEXT                         LEFT        LAST                         PASSED       UNIT                         ACTIVATES
Di 2017-09-05 21:10:12 CEST  22h left    Mo 2017-09-04 21:10:12 CEST  1h 9min ago  systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.serv
Mo 2017-09-11 00:00:00 CEST  6 days left Mo 2017-09-04 20:55:51 CEST  1h 23min ago fstrim.timer                 fstrim.service

Der alte Cronjob hatte eine Konfigurationsdatei in /etc/sysconfig in der man die Schonzeit für Dateien in /tmp und /var/tmp konfigurieren konnte. Beim Systemd-Job übernehmen die Konfigurationsdateien von systemd-tmpfiles diesen Job. Die dazugehörige Manpage ist tmpfiles.d (5).

Die Standardatei /usr/lib/tmpfiles.d/tmp.conf erklärt auch ganz brav diese Verzeichnisse in Ruhe zu lassen. Das ist zwar nicht ganz was ich möchte, aber auch nicht Grund meines Problemes.

# Clear tmp directories separately, to make them easier to override
# SUSE policy: we don't clean those directories
q /tmp 1777 root root -
q /var/tmp 1777 root root -

Die schuldige Konfiguration fand sich in /etc/tmpfiles.d/tmp.conf. Hier muss, bei einem der vielen Versionsupgrades welche mein System hinter sich hat, ein kleiner Übertragungsfehler passiert sein.

d /tmp 1777 root root 0d
d /var/tmp 1777 root root -
x /tmp/* - - - - root

Mit dem Alter Null Tage wird systemd-tmpfiles angewiesen alle Dateien zu löschen, egal wann sie zuletzt modifiziert wurden. Auch wenn dies die meißten Anwendungen in meinem System klaglos hinnahmen sorgte es natürlich für einiges WTF was meine eigenen Skripte und die die virtuellen Python-Umgebungen anging. Die korrektur des Wertes auf einen Tag hat mein Problem erfolgreich gelöst.

d /tmp 1777 root root 1d
d /var/tmp 1777 root root -
x /tmp/* - - - - root

Und das schöne an Systemd ist, dass man so eine Änderung dann auch gleich sehr leicht testen kann.

sudo systemctl start systemd-tmpfiles-clean.service

Eine Anwendung welche mit dem agressiven Aufräumen der temporären Dateien gar nicht klar kommt ist übrigens meine früher so geliebter Browser Opera. Nachdem die temporären Dateien weggräumt wurden findet dieser seine bereits laufende Instanz nicht mehr und fliegt dann beim Versuch ein zweites mal das gleiche Profil zu öffnen ordendlich auf die Fresse. Dies hat mich hinreichend genervt, so dass ich kürzlich zum Firefox gewechselt bin. Seit ich kurz darauf die hier beschriebene Fehlkonfiguration behoben habe funktioniert aber auch der, inzwischen von mir nicht mehr wirklich genutzte, Opera wieder tadellos.

As part of the work for the openSUSE wiki upgrade and move, I had to package a bunch of MediaWiki extensions. We'll use the MediaWiki 1.27.x LTS release, which means the extensions need to work with this version.

When it comes to packaging, there are three categories of extensions:

The Good

These extensions are hosted on phabricator.wikimedia.org, and you can easily download a tarball matching your MediaWiki version using the "Download snapshot" link on the extension page.

Packaging these extensions is easy - just unpack the tarball and copy/package everything to the extension directory.

These extensions are standardized enough to use a spec file template - usually I only had to adjust the extension name, tarball name and version. Speaking of the version - most extensions don't have explicit version numbers, so I decided to use the tarball date instead.

An example for this category is Auth_remoteuser (extension page, package) which we use to keep the "nice" wiki login form.

The Bad

These extensions are hosted on GitHub and typically only have a "master" branch. They usually still work with MediaWiki 1.27.x, but there's a small risk that they require features added in newer MediaWiki versions, and this risk will grow over time.

On the packaging side, they are as easy as the "good" extensions.

An example is the ParamProcessor extension (extension page, package) which is needed by the Maps extension

The Ugly

These extensions can be hosted on phabricator.mediawiki.org or GitHub, so there are "god ugly" and "bad ugly" extensions ;-) The thing that makes packaging really ugly is that they don't include all the code they need. Instead, you have to download the missing parts with composer.

composer works fine in a "real" system, but makes packaging hard. Running it from the spec will obviously fail because OBS doesn't allow network connections while building a package (and even if it's annoying in this case, not having network access during build is a good thing[tm]).

My solution is a little script that unpacks the extension tarball and runs "composer install --no-dev" inside the extension directory. The most important part is the "--no-dev" parameter because that avoids lots of superfluous things. Afterwards, I build a tarball from the "vendor" directory and add it to the package.

Yeah, I know that's not nice - guess why I named this section "The Ugly" ;-)

One of the packages that need a "composer install" run is the GitHub extension (extension page, package including script to run composer).

Luckily, "ugly" only applies to packaging. The extensions and their maintainers are for sure not ugly - for example, the maintainer of the GitHub extension was very fast in fixing a bug :-)

Kein Aprilscherz: Canonical gibt Unity 8 auf und wechselt für Ubuntu 18.04 LTS zurück auf Gnome.

Fokus auf IoT und Cloud

In einem Blog Post hat Mark Shuttleworth, Gründer von Canonical, geschrieben:

I’m writing to let you know that we will end our investment in Unity8, the phone and convergence shell. We will shift our default Ubuntu desktop back to GNOME for Ubuntu 18.04 LTS.

Übersetzung:

Ich schreibe um euch wissen zu lassen, dass wir unsere Beteiligung an Unity8, der Smartp...

Back to business... mit einer kurzen Erklärung der Downtime und wie die Probleme gelöst wurden.

Hallo, liebe Leser!

Dies ist mein erster Post 2017 und daher lasst uns mit einem sehr verspäteten 'Frohes neues Jahr!' und den besten Wünschen für 2017 beginnen

Aber kommen wir direkt zum Geschäft zurück:

Downtime

Einigen wird es nicht entgangen sein, dass der Blog und die Webseite von crowbyte eine weile offline war. Zunächst einmal entschuldige ich mich für alle eventuell aufgetretenen Un...

I just released PostfixAdmin 3.0.2.

This release fixes a security bug - admins could delete protected aliases like abuse@ (CVE-2017-5930). Besides that, some non-security bugs were fixed. Read the official announcement for details.

Packages for openSUSE Tumbleweed and updates for Leap are already on their way to the official repos :-)

Some weeks ago, someone asked on the opensuse-wiki mailinglist if it's acceptable to move documentation (in this case about Icecream) from the openSUSE wiki to the upstream repo on github. One of the arguments was:

I think I should store anything I do for the openSUSE project somewhere in the openSUSE.org domain, not in a RedHat.org or Canonical.org domain or a SourceForge.net or GitHub.com domain.

While this sounds like a valid argument and for sure shows good intentions, I wrote a longish reply:

You are overlooking an important point here - collaboration.

It doesn't make sense to think of "we" vs. "them" when it comes to other distributions or upstream projects. It's quite the opposite - everybody can save time by working together with other distributions, upstream projects etc. We have more important things to do than re-inventing the wheel just because we need a green one.

As an example: You might know that I maintain AppArmor in openSUSE and also contribute upstream (OMG, the upstream mailinglist is @lists.ubuntu.com, not at a "neutral" domain!)

Some not-so-known details:

• I implemented support for new AppArmor rule types (dbus, signal etc.) in aa-logprof, but those are not yet supported in the upstream kernel (and also not in openSUSE) - so currently only Ubuntu users benefit from that
• I always send patches upstream so that everybody can benefit (no, saying "use openSUSE, it's fixed there" is not a good idea ;-)
• In 2015, I visited DebConf (I'd guess I was the only one there who had never used Debian before) and even gave a talk.
• I closely follow AppArmor-related bugreports in Debian and Ubuntu, and help them to get things fixed - even if it's distro-specific

So, tell me - am I working for the enemy? ;-)

 

BTW: This isn't a one way road. Quite some AppArmor contributions done by Ubuntu (some other upstream developers work for Canonical) and Debian contributors end up in openSUSE ;-)

Needless to say that AppArmor is just an example. What I said is basically valid for every package, project, whatever. Either you collaborate (and everybody wins), or you "cook your own soup" and never find out that someone else has a receipe for a much more tasty soup ;-)

Since I talked a lot about AppArmor in the above text, let's see what's new there.

You might have noticed that there were some AppArmor releases recently:

• AppArmor 2.9.4 (with several bugfixes and profile updates) was already released as an update for openSUSE 13.2 shortly before it went out of support.
• AppArmor 2.10.2 (also with several bugfixes and profile updates) is already available in Tumbleweed, and updates for Leap 42.1 and 42.2 are under review
• AppArmor 2.11 (with lots of improvements and new features - for example, I rewrote the handling of file rules in aa-logprof etc.) is on its way to Tumbleweed (SR 453537), but it seems splitting off libapparmor into its own spec file (to fix a build loop) triggered a bug in the factory-auto review bot. Given my talent to find bugs, I'm not even surprised ;-)

The rewrite of the file rule handling resulted in a nice series of 42 patches which replace 1600 lines of code using a deeply nested array with 1200 lines with the more readable and easier maintainable FileRule and FileRuleset classes (a total of 530 lines) and functions using these classes. Even with 400 lines less code, I added some small features (for example, rules with leading permissions like "r /etc/fstab," are now supported) and fixed some bugs along the way.

The old code to handle file rules had very few unittests, which made this rewrite (and especially avoiding breakage and regressions) quite challenging. On the positive side, my patch series added full test coverage for the FileRule and FileRuleset classes, and also added unittests for most of the functions using FileRule and FileRuleset. (Unfortunately full test coverage isn't always easy, especially for the interactive parts of aa-logprof.) Those unittests add about 1400 lines of code, but as long as such additions happen in the tests directory, I'm more than happy about them ;-)

Oh, and the final challenge hit the other AppArmor developers. AppArmor has the policy that all patches have to be reviewed, and reviewing the whole patch series (which summed up to +2600 -1628 lines) took some time ;-)

That all said, let's not forget to answer where the documentation should live:

To come back to the origin of this discussion: I don't care too much where the Icecream developers host their documentation as long as

• it is complete and up to date (having it at the developers' favorite place makes this more likely)
• it can be easily found (also not a problem, it's linked from the wiki, and your favorite search engine will also find it)

I see the main purpose of the openSUSE wiki to provide openSUSE-specific information.

Information about upstream projects (even if a project is done by openSUSE) is "nice to have", but it's also ok if it lives upstream. It's better have one good upstream documentation than pages at 5 distro wikis that are all incomplete and out of date ;-)

BTW: The question "Am I working for the enemy?" was mostly meant as a rhetoric question - but if you want to answer nevertheless, please add a comment ;-)

I was nominated to run for the openSUSE Board, and finally decided to run ;-)

I use openSUSE since years (actually it was still „SuSE Linux“ with lowercase „u“ back then), started annoying people in bugzilla, err, started betatesting in the 9.2 beta phase. Since then, I reported more than 1200 bugs. Later, OBS ruined my bugzilla statistics by introducing the option to send a SR ;-)

More recently, I helped in fighting the wiki spam, which also means I‘m admin on the english wiki since then, and had some fun[tm] with the current server admin. I‘m one of the founding members of the Heroes team (thanks to Sarah for getting the right people together at oSC16!) Currently, I work on the base server setup (using salt) for our new infrastructure and updating the wiki to an up-to-date MediaWiki version.

You can find me on several mailinglists and on IRC, and of course I still scare people in bugzilla. I‘m also a regular visitor and speaker at the openSUSE Conference, and visit other conferences as time permits.

Besides openSUSE, I work on AppArmor and PostfixAdmin – both upstream and as packager. Also, I‘m admin on several webservers (all running with Leap).

My day job has nothing to do with computers. I produce something you can drink that is named after a software we ship in openSUSE ;-)

Oh, and I collect funny quotes from various mailinglists, IRC, bugzilla etc. that then end up as random signatures under my mails, so be careful what you write ;-)

Issues I can see

• You probably know „DRY“, so – see the next paragraph

Aims/Goals

• speed! We have too many issues hanging around for too long, and that‘s annoying for people who suffer from them. Especially small things should (and can!) be solved quickly.

• clear responsibilities! Part of the speed problem is that it‘s sometimes hard to find out who can fix something, and hunting down people takes time.

• don‘t talk (too much) – do it! Sometimes we need to discuss things, but often just doing them works best. Obviously I can‘t do everything alone, so I want to encourage people to help whereever they can. „I don‘t have knownledge how to do this“ doesn‘t count – for example, updating a wiki page or reporting a bug isn‘t hard ;-) and typically people really start to report bugs once they understand that this gives them the right to complain (quoting Pascal Bleser: „Always file a bug: if it‘s not in Bugzilla, then it‘s not there“)

• longer days! Maybe I should move to Bajor – I heard they have 26 hour days there, which would solve some of my time problems ;-))

Why you should vote for me?

• I tend to kick people to ensure they work faster and fix things. This is your chance to kick me!

• Help me to find out if I can get the thing in the (non-random) signature of this blog post done!

Things I‘ll never do:

• use a stable release on my main computer – Tumbleweed is just too good ;-)

• open a bugreport if fxing it and sending a SR is faster

• be too serious – hey, our motto is „Have a lot of fun...“ ;-)

• drink beer ;-) (sorry, not even openSUSE beer)

Contact Details:

• Mail: anything @cboltz.de - or use my IRC nick @opensuse.org
• IRC: cboltz
• http://blog.cboltz.de (some more posts would be nice, but then you wouldn‘t believe the „don‘t talk – do it!“ ;-)
• https://connect.opensuse.org/pg/profile/cboltz
• https://en.opensuse.org/user:cboltz

I wish all candidates good luck, hope that we‘ll see lots of voters – and wish everybody all the best for 2017!

PS: Non-random signature (yes, I know it's unusual for a blog post to have a signature at all, so this will stay a rare exception) – and while I have serious doubts about the second paragraph, I‘m very sure about the first ;-)

--
If you run for the Board this year and get elected, I can see my sanity would be doomed
But in a good way ;)
[Richard Brown]

Bei uns ist immer noch ein, inzwischen vermutlich als antik geltender, ASUS-Laptop mit einem Core2 Duo und 3 GiB RAM im Einsatz, bisher mit openSUSE 13.1. Angesichts dessen Supportendes, war aber ein update nötig. Und da auch das damals vorinstallierte Windows Vista sein Lebensende erreicht hatte, und seit mehreren Jahren nicht mehr genutzt war, führte ich eine Neuinstallation mit openSUSE Leap 42.2 durch. Wie bei jeder Rechnerneuinstallation stolperte ich dabei über ein paar Eigenarten, aber insgesamt läuft das System wunderbar.

Insgesamt fühlt sich das System flotter an als vorher. Der Hauptgrund dafür ist wohl, dass das System recht sparsam mit dem Hauptspeicher umgeht. So nutzt es wenn man die üblichen Anwendungen, wie KMail und ownCloud, im Hintegrund hat und dann noch DM Fotowelt, ein mittelgroßes Open-Office-Dokument mit Fotos und Firefox mit einer zweistelligen Anzahl Tabs offen hat nur run 2 GiB seines Hauptspeichers. So kommt das System dann trotz vollverschüsselter Festplatte und ohne SSD auf nutzbare Geschwindigkeit.

Ein Wermutstropfen ist, dass ich die in KDE eingebaute Volltextsuche abschalten musste. Obwohl das System bei Installation und während des Zurückkopierens aller Dateien auch über Nacht stabil lief, war damit Schluss sobald die Volltextsuche anfing die Dateien zu indizieren. Nach fünf bis zehn Minuten war der Rechner komplett eingefroren. Auch ein SSH auf den Rechner war nicht mehr möglich.

Ein weiterer interessanter Bug ist, dass die Plugins von Parley nicht funktionieren. Diese haben in der Shebang kf5kross als Interpreter angegeben, allerdings wird dieses nicht installiert.

Da es für meine geneigte Leserschaft (auch die in den Planeten von OSBN und Debianforum.de) vielleicht interessant ist oder jemand jemanden kennt: Mein Arbeitgeber sucht derzeit Mitarbeiter für Kundenbetreuung, Support & Service im Bereich Linux.

Zur Verstärkung unseres Teams in Königsbrunn suchen wir Sie.

Wir freuen uns auf Sie als:

Mitarbeiter (m|w) Kundenbetreuung, Support & Service

Ihre Aufgaben in unserem Haus umfassen:

• Durchführen von Hardwaretestes
• Technische Beratung und Unterstützung von Kaufinteressenten telefonisch als auch in schriftlicher Form, vorwiegend per E-Mail
• Technische Hilfestellung bei Fragen zu Betriebssystemen der Linuxfamilie, insbesondere Ubuntu
• Prüfung von Kundengeräte auf Hard- oder Softwarefehler sowie deren Beseitigung

Mehr Infos gibt es im Firmenblog. Für Rückfragen stehe ich natürlich auch gerne zur Verfügung.