Nie zwykłem recenzować wydarzeń, ale podzielę się kilkoma przemyśleniami po tegorocznym Infoshare. Organizatorzy po kilku latach mają już wprawę i wszystko odbywa się sprawnie i profesjonalnie. Świetna lokalizacja (i parking!), dobrej jakości technikalia oraz przyjemna atmosfera. Niemniej trudno z roku na rok utrzymać wyśrubowany poziom. Zeszłoroczna edycja dostarczyła więcej wrażeń i ciekawych wystąpień. W tym roku zabrakło porywających przemówień takich jak prelekcja Gabriela Baldinuciego z 2013 czy charakterystycznych postaci.

Dużo mówiło się o trendach i kierunku rozwoju. Wniosek jest smutny. Pierwszego dnia prelegent zastępczy mówił o „10 trendów tu i teraz”. Niemal wszystkie sprowadzały się do zbierania danych o użytkownikach po to, żeby targetować na nich reklamy. Wygląda na to, że nikt nie ma pomysłu na stworzenie czegoś wartościowego, na czym można zarabiać. Szczytem możliwości jest sprzedaż danych behawioralnych.

Jedynym wyróżniającym się trendem był druk 3D. Nie dziwię się, ludzie mają dosyć „tworzenia”, które kończy się milion pierwszą aplikacją dla jednego promila. Druk 3D pozwala zrobić coś, co da się dotknąć. Myślę, że zaczyna nam brakować takiej fizyczności. Dlatego też doceniony został startup robiący grę edukacyjną Professor Why. Clue zabawy w chemię jest rozszerzona rzeczywistość. Znowu – karty, które można dotknąć diametralnie zwiększają zaangażowanie najmłodszych.

Zresztą startupy były najciekawszym elementem tegorocznego Infoshare. Asia spędziła cały pierwszy dzień z zainteresowaniem słuchając pitchy.

Ja drugiego dnia popełniłem błąd taktyczny. Mając do wyboru „Architekturę Stack Oveflow“ i cośtam o Twitterze, poszedłem na to drugie. Sprawnie poprowadzona prezentacją o pierdołach. Ludzie oglądając telewizję twittują, że ogladają telewizję; dzięki temu BMW może puścić reklamę i napastować bezpośrednio (no, na twitterze) osoby oglądające reklamę w tym czasie. Znowu: reklamy, targetowanie, reklamy, reklamy. Rzyg. Podobnie z telewizorami hybrydowymi HbbTV. Pokazany przykład zastosowania — reklama samochodu.

Jednak spora część uczestników odnajdowała się w tematach odmóżdżających – reklamy i telewizja. Dlatego mimo najszczerszych chęci nie udało mi się nawiązać z nimi rozmowy w czasie imprezy integracyjnej na stadionie. Ani z ludźmi, których celem życia jest stworzenie kolejnej stronki.

Z nieoczekiwanych plusów: pierwszego dnia miałem okazję naprawić bankomat bitcoinowy. Ha!

Używam socket activation w systemd do odpalania demona FTPD. Plus jest taki, że jak na dłoni widzę wszystkie sesje i mogę je wybiórczo ubijać. Chociaż raczej nie ma potrzeby, bo użycie zasobów jest skutecznie limitowane mechanizmami z systemd.

$ systemctl | grep vsftp
  vsftpd@406-109.107.25.117:21-93.154.247.87:43126.service            loaded active running   vsftpd instance service for /vsftpd@406.service (93.154.247.87:43126)
  vsftpd.socket                                                       loaded active listening vsftpd incoming socket


$ systemctl status vsftpd@406-109.107.25.117:21-93.154.247.87:43126.service
● vsftpd@406-109.107.25.117:21-93.154.247.87:43126.service - vsftpd instance service for /vsftpd@406.service (93.154.247.87:43126)
   Active: active (running) since Thu 2014-03-27 11:40:13 CET; 1min 9s ago
   CGroup: /system.slice/system-vsftpd.slice/vsftpd@406-109.107.25.117:21-93.154.247.87:43126.service
           ├─11643 vsftpd: ::ffff:93.154.247.87: connected
           └─11645 vsftpd: ::ffff:93.154.247.87/ftp: RETR pidora-18-r1c.img

Jest też niestety minus — jeśli demon vsftpd kilkukrotnie zakończy działanie błędem, to w końcu systemd wyłączy nasłuchujące gniazdko.

Przydałaby się więc automatyka włączająca je z powrotem. W pierwszym odruchu zrobiłem parę jednostek, które używają curl do sprawdzenia stanu usługi:

$ cat ftp-check.timer
[Timer]
OnCalendar=hourly

[Install]
WantedBy=vsftpd.socket

$ cat ftp-check.service
[Unit]
OnFailure=vsftpd.socket

[Service]
ExecStart=/usr/bin/curl --silent --noproxy localhost ftp://localhost:21 -o /dev/null

Jak to działa? Jednostka timer:

• aktywowana jest co godzinę
• polecenie enable spowoduje, że zaczyna działać razem z vsftpd.socket
• ponieważ nie ma explicité podanego co jest włączane przez timer, to aktywowana jest usługa o takiej samej nazwie: ftp-check.timer->ftp-check.service

Działanie "usługi sprawdzającej" również zawiera się w kilku punktach:

• start usługi powoduje próbę połączenia curlem do FTP
• po zakończeniu curla sprawdzany jest jego kod wyjścia:
  • jeśli połączenie przebiegło pomyślnie, ftp-check.service po prostu się kończy
  • jeśli curl nie mógł się połączyć, to kod wyjścia wskazuje na błąd; usługa przechodzi w stan failed; ponieważ zdeklarowano OnFailure=, błąd powoduje, że systemd aktywuje wskazaną jednostkę. Powoduje to ponowne wprowadzenie gniazdka vsftpd w stan nasłuchujący — powrót do normalnego działania

Rozwiązanie działa, jednak z opóźnieniem. Zastanowiwszy się nad tym, wpadłem na prostsze rozwiązanie:

$ cat vsftpd@.service
[Unit]
Description=vsftpd instance service for %c
OnFailure=vsftpd.socket
[...]

W ten sposób padający vsftpd sam od razu podnosi gniazdo.

A tak w ogóle to yum install icinga.