От това, което прочетох се надявах да ми се падне Omnikey четец, но в избраният от мен офис на ЦКБ такива нямаше – единствената опция беше ACS. Понеже напоследък съм мързелив, а и ми трябваше спешно рискувах и го взех. Последното след попълването на един тон документация от момичето в офиса, което беше леко неориентирано, изглежда нямаше кой знае какъв опит с издаване на сертификати, но с малко помощ от приятели (с цената от две телефонни обаждания) все пак се справи.

И така, за мен остана да изчакам края на работния ден, да се прибера и да видя какво ще се получи. Ами смело мога да заявя, че четецът работи out of the box с ccid драйверът по подразбиране.

pcscd сървисът е стартиран:

[Nick@Pegasus ~]$ systemctl status pcscd.service
pcscd.service - PC/SC Smart Card Daemon
Loaded: loaded (/lib/systemd/system/pcscd.service; disabled)
Active: active (running) since Tue, 22 Nov 2011 20:56:10 +0200; 2h 9min ago
Main PID: 8758 (pcscd)
CGroup: name=systemd:/system/pcscd.service
└ 8758 /usr/sbin/pcscd -f

Исталирани са следните пакети:

[Nick@Pegasus ~]$ yum list pcsc-*
Installed Packages
pcsc-lite.x86_64                        1.7.4-6.fc16                  @fedora
pcsc-lite-ccid.x86_64                   1.4.5-1.fc16                  @fedora
pcsc-lite-devel.x86_64                  1.7.4-6.fc16                  @fedora
pcsc-lite-libs.x86_64                   1.7.4-6.fc16                  @fedora

[Nick@Pegasus ~]$ yum whatprovides pcsc-lite
pcsc-lite-1.7.4-6.fc16.x86_64 : PC/SC Lite smart card framework and applications
Repo        : fedora

[Nick@Pegasus ~]$ yum whatprovides pcsc-lite-ccid
pcsc-lite-ccid-1.4.5-1.fc16.x86_64 : Generic USB CCID smart card reader driver
Repo        : fedora

Ето и как се разпознава самият четец (dmesg output):

[787202.753102] usb 1-1.5.4: new full speed USB device number 13 using ehci_hcd
[787202.841264] usb 1-1.5.4: New USB device found, idVendor=072f, idProduct=90cc
[787202.841267] usb 1-1.5.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[787202.841269] usb 1-1.5.4: Product: CCID USB Reader
[787202.841270] usb 1-1.5.4: Manufacturer: ACS
[789782.064529] usb 1-1.5.4: USB disconnect, device number 13

И малко по-подробно (lsusb -vd):

lsusb -vd 072f:90cc
 
Bus 001 Device 015: ID 072f:90cc Advanced Card Systems, Ltd ACR38 SmartCard Reader
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x072f Advanced Card Systems, Ltd
  idProduct          0x90cc ACR38 SmartCard Reader
  bcdDevice            1.00
  iManufacturer           1 ACS
  iProduct                2 CCID USB Reader
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           93
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass        11 Chip/SmartCard
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      ChipCard Interface Descriptor:
        bLength                54
        bDescriptorType        33
        bcdCCID              1.00
        nMaxSlotIndex           0
        bVoltageSupport         7  5.0V 3.0V 1.8V
        dwProtocols             3  T=0 T=1
        dwDefaultClock       4000
        dwMaxiumumClock      4000
        bNumClockSupported      0
        dwDataRate          10752 bps
        dwMaxDataRate      344100 bps
        bNumDataRatesSupp.      0
        dwMaxIFSD             247
        dwSyncProtocols  00000000
        dwMechanical     00000000
        dwFeatures       00010030
          Auto clock change
          Auto baud rate change
          TPDU level exchange
        dwMaxCCIDMsgLen       271
        bClassGetResponse      00
        bClassEnvelope         00
        wlcdLayout           none
        bPINSupport             0
        bMaxCCIDBusySlots       1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              16
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)

Моделът на картата ми е T&S DS/2048 (L), което налага инсталирането на два допълнителни пакета от хранилището на Инфонотари, a именно – bit4id-ipki и infonotary-scardmanager.

Остава само настройката на browser-а, който в случая е firefox. Сертификатът може да се инсталира директно от линка изпратен от Инфонотари чрез e-mail, а за улеснение на конфигурацията може да се добави следният firefox add-on – InfoNotary Configurator for Mozilla, . Ако при отварянето на тестовият линк (тестът може да бъде направен и от Preferences –> Signature Test на добавката на Инфонотари), отговорът е Data Accepted, то всичко е наред и можем да подписваме на воля.

Допълнителна информация:

Загубих доста време да разбера какъв е точният модел на четеца. Както може да се види от output-а по-горе то се разпознава като ACR38. На капачето му обаче е изписано ACR38T, а според една от техническите спецификации на сайта на производителя, а и според външният му вид, то това е ACR38DT. Според същата спецификация, въпросният четец работи с ccid, само ако е с firmware 1.12, и явно моят е такъв. В противен случай вероятно ще се наложи инсталирането на vendor драйверите.

Ето как изглежда на практика:

Полезни линкове (дадени са и в текста по-горе):

1. Използване на квалифициран електронен подпис в Mozilla Firefox за Linux
2. Използване на хранилищата на InfoNotary
3. InfoNotary Configurator for Mozilla
4. Инсталация на драйвери за четец и смарт карта в Linux

Умишлено не посочвам линк към „Инсталация на драйвери за четец и смарт карта в Linux“. Въпреки, че статията е относително актуална, то в нея има някои неточности, които могат да доведат до объркване. Освен това е и доста Ubuntu ориентирана. Но това, не е кой знае какъв проблем, освен че имената на пакетите във Fedora са други.  Проблемът е друг, че по начинът, по който е написан краят на статията, може да се остане с впечатлението, че е нужно да се инсталира и OpenSC. Това не е необходимо! OpenSC, въпреки че разпознава правилно четеца, зарежда и използва CNS драйвера. Освен това, ACS липсва от списъкa с поддържаният от проекта хардуер, но пък е споменат в списъкът с поддържани устройства от CCID.

И така в резюме: ACS ACR38DT от Инфонотари работи под Fedora 16 с Firefox 7, без да е необходимо да се инсталират допълните драйвери за картовия четец.

Рдакция /24.11.2011/: Статията във wiki-то на Инфонотари е редактирана, и е доста по-точна в момента. Така че включвам и линк-а към нея.

• Chrony заменя ntpd като основен метод за синхронизация на време
• ext4 отдавна е част от дистрибуцията, но сега ext4 драйвера се използва за монтирането и на ext2 и ext3 дялове.
• 1000 System accounts – преместване на границата между потребителски и системни акаунти от UID/GID 500, на UID/GID 1000
• Gnome 3.2
• KDE 4.7
• Много подобрения и добавени приложения свързани със виртуализацията и облачните услуги

Екипът на Fedora прави хубав жест с решението да посвети Verne  на големият Денис Ричи.

Повече подробности могат да бъдат намерени в Release Notes, Feature List и официалният анонс.

По стара лична традиция upgrade-нах от 15-та към 16-та версия посредством yum. Въпреки че не е сред официално препоръчваните начини за update, си остава най-удобният за мен. Процедурата е следната:

Импортиране на ключа:

rpm --import https://fedoraproject.org/static/A82BA4B7.txt

Update на yum:

yum update yum

Изчистване на кеш-а:

yum clean all

И самия update:

yum --releasever=16 --disableplugin=presto distro-sync

Имаше малко проблеми със счупени зависимости, та се наложи преди това да премахна:

yum -y remove kino, libnih, libmtp-hal

След това всичко мина гладко и можеше да се насладя на добрата работа на Artwork тима.

--- kannel.epel.spec    2011-10-28 16:29:01.000000000 +0300
+++ kannel.spec 2011-10-28 16:31:48.000000000 +0300
@@ -1,18 +1,18 @@
 Summary: WAP and SMS gateway
 Name: kannel
-Version: 1.4.3
-Release: 5%{?dist}
+Version: 1.5.0
+Release: 20111028%{?dist}
 License: BSD
 Group: System Environment/Daemons
 URL: http://www.kannel.org/
-Source0: http://www.kannel.org/download/%{version}/gateway-%{version}.tar.bz2
+Source0: http://www.kannel.org/download/kannel-snapshot.tar.gz
 Source1: kannel.logrotate
 Source2: kannel.init
 Source3: kannel.conf
 Source4: gw-config
 # TODO: a corresponding configure.in patch could be upstreamable?
-Patch0: gateway-1.4.3-ssldetect.patch
-Patch1: gateway-1.4.1-typesh.patch
+#Patch0: gateway-1.4.3-ssldetect.patch
+#Patch1: gateway-1.4.1-typesh.patch
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
 BuildRequires: bison, byacc, flex, ghostscript
 BuildRequires: libxml2-devel, openssl-devel, zlib-devel, pcre-devel
@@ -69,9 +69,9 @@
 
 %prep
-%setup -q -n gateway-%{version}
-%patch0 -p1 -b .ssldetect
-%patch1 -p1 -b .typesh
+%setup -q -n kannel-snapshot
+#%patch0 -p1 -b .ssldetect
+#%patch1 -p1 -b .typesh
 %{__chmod} -c -x gwlib/html-entities.def # for -debuginfo, as of 1.4.3
 
@@ -147,6 +147,7 @@
 %{_bindir}/seewbmp
 %{_bindir}/wmlsc
 %{_bindir}/wmlsdasm
+%{_bindir}/decode_emimsg
 %{_sbindir}/*
 %{_mandir}/man?/*
 %attr(0750,kannel,kannel) %dir %{_var}/log/kannel/
@@ -164,6 +165,9 @@

I assumed that the two patches applied to version 1.4.3 are not necessary, because they probably are part of the svn code.

There was a build error on the first run:

RPM build errors:
Installed (but unpackaged) file(s) found: /usr/bin/decode_emimsg

so I had to add „%{_bindir}/decode_emimsg“ in the %files section.
The spec file expect the availability of the following files in the SOURCE directory: kannel.logrotate, kannel.init, kannel.conf, gw-config

The kannel.spec file can be found here.
The command used to build the rpm is:

rpmbuild -ba kannel.spec

Another way to do the trick:
http://www.blogalex.com/archives/23

Малко откъслечни мисли

Разбира се основното е забавянето от 242 дни. Както на самия CentOS 6.0 така и на Security ъпдейтите за 5.6, които също „излипсваха“ за известно време в началото на 2011.  Основната теза защитавана от разработчиците на дистрибуцията е липсата на ресурс и лошо стечение на обстоятелствата (излизането на RHEL 5.6 и 6.0 за относително кратък период). В общи линии нещата бяха представени така – Трябваше да избираме кое да направим първо, ние избрахме 5.6, а Scientific Linux 6.0, за това те ни изпревариха. Другата основна догадка сред community-то бе, че стъпките предприети от RedHat с идеята да затруднят Oracle в копирането на RHEL и предлагането на support за него, са попречили сериозно и на CentOS но разработчиците точно и ясно неколкократно отрекоха това да е проблем. Модифицираните от екипа на CentOS пакети са 11, премахнатите от CentOS пакети са 10 и е добавен 1, което както и да го гледаме е нищожно малко. Това не трябва да създава впечатлението обаче, че реализирането на CentOS е работа за 2 дни. Всеки пакет се build-ва от srpm-а предоставен от RedHat, така че несъмнено е времеемко и изисква адекватно внимание. Въпросът е в това, че пускането на предния major release (5.0) е отнело само 28 дни. Какво толкова се е променило през изминалите от тогава 4 години. Никой не знае. Дори и хора, като Dag Wieers не са наясно  (всеки ползващ RedHat дериват би трябвало да е наясно кой е той). В това и за мен се крие основния проблем – липсата на информация. Имаше неколкократни запитвания в мейл листа и официалния форум, имаше и предложения за евентуална помощ, но единственото, което се имаше насреща бяха уклончиви и на моменти дори арогантни отговори, в повечето случаи дори не от пряко ангажирани с процеса хора. Чат пат се включваше и Karanbir Singh, но без някаква кой знае каква конкретика.  Това е нещото, което ме подразни много повече от самото забавяне (за щастие нямах планирани машини за пускане в production, освен една миграция, която спокойно можех да забавя). Да не говорим че се започнаха дори и подигравки, когато се случеше поредното „побутване“ с 2 седмици на полу-официалния schedule (още по-лошото е, че дори нямаше history, просто се сменяше датата).

Силно се надявам хората стоящи зад проекта сериозно да се замислят над това случващото се и да поемат подадената им ръка, без да подхождат с високомерие, каквото на моменти се демонстрираше. Когато си вдигнал летвата толкова високо, нивото се поддържа доста трудно, особено когато ресурсът е ограничен, но е по-добре да кажеш че се нуждаеш от помощ, отколкото системно да отклоняваш адекватни въпроси с фрази от рода „Не бързайте, ще стане“.

Графично представяне, с което да обоснова горното

Инспириран от тази статия и наличната информация във Wikipedia и announce мейл листите на RedHat и дистрибуциите базирани на него направих сравнителна табличка и графика за забавянията (в дни) спрямо Redhat release-ите (започва от 4.4, понеже тогава е първият Oracle Unbreakable release).

За пресмятането на разликата в дните ползвах ето този one-line perl script:

perl -e 'use Date::Calc qw(Delta_Days); printf "%d\n", Delta_Days(first_date,second_date);'

където датите са във формат – „yyyy,mm,dd“

Таблицата:

И графично представяне на горното (клик за по-голям размер):

От друг ъгъл и с малко transparency (клик за по-голям размер):

Както се вижда основно от графиките, забавянията напоследък са постоянни и при CentOS бележат регрес, чиито апогей бе забавянето на 6-цата. Докато при SL и особено Oracle се отбелязва прогрес. Не знам колко е голям екипа на Oracle, естествено на тях им и плащат за това, но не може да им се отрече че що се касае до време се справят добре. SL е горе-долу на едно ниво с CentOS, с изключение на последните няколко release-а, където бие по точки. Техният тим е обявен на сайта им, и никак не е голям. Те също са на заплата в CERN, но по стечение на обстоятелствата мисля, че дистрибуцията не им е сред топ приоритетите. Паралелно си поддържат и около 9000 сървъра и 3000 декстоп станции по техни думи.

Та въпроса, какво става с CentOS си виси на дневен ред и си го задавам не само аз:

Matt Simmons е написал много добър пост темата тук. Понеже нямах физическата възможност да следя всеки threads в CentOS-devel мейл листа (по груби спомени бяха няколко хиляди) преди малко попаднах на ето този мейл там, в което е написано следното /което и донякъде отговаря на въпроса за забавянето само по себе си/:

This is NOT the case with 6.0.  First off, we can not use any of the
existing infrastructure to build on because we can not build on a CentOS
4 or CentOS 5 machine because of the changing of MD5SUM in the RPMs
themselves.

Secondly, the distribution will not build on the Beta (much like the 3.x
release and UNLIKE the 4.0 and 5.0 releases).  Not only that, but
upstream used many "non released" packages to build on ... packages we
can not see or get.

Now, because of those things and because we choose to stop work on 6.0
to build out 5.6 and 4.9, the 6.0 release is late.

Но няколко мейла по-натам Dag Wieers прави доста ценно включване, което и обяснява неговото оттегляне, както чувството за безизходица обзело крайните потребители след отговори от рода на „Ще стане, когато стане“, и объркването от липсата на заявка за помощ от безспорно „силната“ CentOS общност:

On Mon, 16 May 2011, Johnny Hughes wrote:

> It will be released when it is released, if you don't like it then leave. 
Before I leave this list let me take you back about 7 years to the
Whitebox mailinglist. You may not remember that Whitebox had a list of
issues of its own, no timely updates, no community effort, lack of good
communication. It was mostly a one-man-effort.

And the people on that list who were not pleased, included Johnny and
Karanbir. And it's striking (and ironic) how similar the discussions went
7 years ago. Johnny said:

   [WBEL-users] WBEL Vs Centos ? :-S
   http://beau.org/pipermail/whitebox-users/2004-December/004761.html

   "If timely updates are not a key factor for you, then WBEL is a great
   distro.  If timely updates are the most important thing you consider
   about the distro you want, then WBEL might not be a fit for you.  That
   is all I have ever said ... and I have never said it meanly."

or:

   [WBEL-users] WBEL Vs Centos ? :-S
   http://beau.org/pipermail/whitebox-users/2004-December/004740.html

   "I just think people should not have the expectation the WBEL is
   community operated, it is not.  It's NOT like debian or gentoo where
   others can get involved.  I know, I tried really hard to do so many
   times.

Karanbir said:

   [WBEL-users] WBEL ...dead?
   http://beau.org/pipermail/whitebox-users/2004-December/004684.html

   "Be a lil difficult to sell that to the IT Manager / CTO : Hang tight
   dude, its comming. Anytime now."

or:

   [WBEL-users] WBEL ...dead?
   http://beau.org/pipermail/whitebox-users/2004-December/004709.html

   "Why ? the other RHEL recompiles dont have this 'its coming, hang on'
   attitude do they ?

   If there is a security issue out there, you can put in a fairly good
   idea as to when its possible to deploy with them. Whats the scene with
   WBEL ?"

The only difference I see is that back then Whitebox had only a fraction
of users, and even less using it for critical mission, while nowadays
people rely even more on timely security updates and releases coming from
CentOS. And people expect to help and contribute to the process to make
that happen.

Which, contrary to what is stated now, was an essential part in the start
and growth of the CentOS project.

Какви са опциите?

• оставаме си с CentOS
• миграция към SL
• ползване на support и съответно RHEL
• ползване на Fedora (няма long time support)
• ползване на друга популярна сървърна дистрибуция (не- Redhat / RPM базирана)

Моят избор за момента е да остана с CentOS – е, освен ако не почна работа във фирма, която си плаща за RHEL :)  С CentOS все пак са и доста други (в това число Facebook, Amazon EC2, Tumblr). Но понеже горчивия привкус от тази история остава, при първа въмозжност ще хвърля един поглед на SL.

Кодът, който съм добавил е съобразен с output-а, който връща към момента whois.register.bg:

DOMAIN NAME: digsys.bg
requested on: 08/09/1991 00:00:00 EEST
processed from: 08/09/1991 00:00:00 EEST
activated on: 08/09/1991 00:00:00 EEST
expires at: 01/01/2012 00:00:00 EET
registration status: Registered
REGISTRANT:
Digital Systems Ltd.
VARNA, 9000
BULGARIA


И в частност полетата „REGISTRANT“ и „expires at“.

Като към скрипта, аз съм добавил следното:

diff -c check.domain.expired_orig.sh check.domain.expired.sh
*** check.domain.expired_orig.sh        2011-02-22 17:02:27.000000000 +0200
--- check.domain.expired.sh     2011-02-22 20:02:27.000000000 +0200
***************
*** 235,240 ****
--- 235,243 ----
      elif [ "${TLDTYPE}"  == "in" ]; # India
      then
          ${WHOIS} -h "whois.registry.in" "${1}" > ${WHOIS_TMP}
+     elif [ "${TLDTYPE}"  == "bg" ]; # Bulgaria
+     then
+         ${WHOIS} -h "whois.register.bg" "${1}" > ${WHOIS_TMP}
      elif [ "${TLDTYPE}"  == "uk" ]; # United Kingdom
      then
          ${WHOIS} -h "whois.nic.uk" "${1}" > ${WHOIS_TMP}
***************
*** 265,270 ****
--- 268,276 ----
      elif [ "${TLDTYPE}" == "jp" ];
      then
          REGISTRAR=`cat ${WHOIS_TMP} | ${AWK} '/Registrant/ && $2 != ""  { REGISTRAR=substr($2,1,17) } END { print REGISTRAR }'`
+     elif [ "${TLDTYPE}" == "bg" ];
+     then
+         REGISTRAR=`cat ${WHOIS_TMP} | ${AWK} '/REGISTRANT:/ && $0 != ""  { getline; REGISTRAR=substr($0,1,17) } END { print REGISTRAR }'`
      fi
 
      # If the Registrar is NULL, then we didn't get any data
***************
*** 308,313 ****
--- 314,341 ----
                esac
              tday=`echo ${tdomdate} | cut -d'/' -f3`
            DOMAINDATE=`echo $tday-$tmonth-$tyear`
+     elif [ "${TLDTYPE}" == "bg" ]; # for .bg dd/mm/yyyy 05/03/2011
+     then
+             tdomdate=`cat ${WHOIS_TMP} | awk '/expires at/ { print $3 }'`
+             tyear=`echo ${tdomdate} | cut -d'/' -f3`
+             tmon=`echo ${tdomdate} | cut -d'/' -f2`
+                case ${tmon} in
+                      1|01) tmonth=jan ;;
+                      2|02) tmonth=feb ;;
+                      3|03) tmonth=mar ;;
+                      4|04) tmonth=apr ;;
+                      5|05) tmonth=may ;;
+                      6|06) tmonth=jun ;;
+                      7|07) tmonth=jul ;;
+                      8|08) tmonth=aug ;;
+                      9|09) tmonth=sep ;;
+                      10)tmonth=oct ;;
+                      11) tmonth=nov ;;
+                      12) tmonth=dec ;;
+                       *) tmonth=0 ;;
+                 esac
+             tday=`echo ${tdomdate} | cut -d'/' -f1`
+             DOMAINDATE=`echo $tday-$tmonth-$tyear`
      else # .com, .edu, .net and may work with others
            DOMAINDATE=`cat ${WHOIS_TMP} | ${AWK} '/Expiration/ { print $NF }'`
      fi

Готовият скрипт с поддръжка на .bg домейни, може да бъде намерен тук.

Примерен output:

./check.domain.expired.sh -d digsys.bg

Domain                              Registrar         Status   Expires     Days Left
----------------------------------- ----------------- -------- ----------- ---------
digsys.bg                           Digital Systems L Valid    01-jan-2012   313

Може да го ползваме в cronjob, и ако домейна изтича в рамките на месец да получим известяване по email.

./check.domain.expired.sh -a -d example.org  -q -x 30 -e mail@example.net

Има възможност и за подаване на повече от един домейн чрез текстов файл (всеки домейн на нов ред).
Въобще всички възможни опции:

Usage: ./check.domain.expired.sh [ -e email ] [ -x expir_days ] [ -q ] [ -a ] [ -h ]
          {[ -d domain_namee ]} || { -f domainfile}
 
  -a               : Send a warning message through email 
  -d domain        : Domain to analyze (interactive mode)
  -e email address : Email address to send expiration notices
  -f domain file   : File with a list of domains
  -h               : Print this screen
  -s whois server  : Whois sever to query for information
  -q               : Don't print anything on the console
  -x days          : Domain expiration interval (eg. if domain_date < days)

Вероятно по-натам на базата на това, ще направя и скрипт за директна проверка в nagios. ]]> http://just4nick.net/blog/archives/950/feed 2 http://just4nick.net/blog/archives/923 http://just4nick.net/blog/archives/923#comments Sun, 13 Feb 2011 12:28:37 +0000 Nick http://just4nick.net/blog/?p=923 Миналата година някъде по същото време, в седмиците покрай MWC се случиха някои наистина изненадващи неща в света на мобилните технологии. Първо Nokia „освободиха“ Symbian:

This is a major breakthrough for the Foundation that shows our commitment to open source and the wider community while enabling the symbian ecosystem to make business as usual. We have tried to lower the adoption barrier to a bare minimum, fostering HW innovation and empowering developers to port the platform to all kind of devices, beyond that of pure personal communication devices… netbooks, perhaps?…

След това обявиха създаването на MeeGo:

MeeGo is an open source, Linux project which brings together the Moblin project, headed up by Intel, and Maemo, by Nokia, into a single open source activity. MeeGo integrates the experience and skills of two significant development ecosystems, versed in communications and computing technologies. The MeeGo project believes these two pillars form the technical foundations for next generation platforms and usages in the mobile and device platforms space.

Бъдещето изглеждаше толкова ясно. Но какво се случи за една година, за да се стигне до новината от петък. Отговорът е  Stephen Elop, първият нефинландец оглавяващ Nokia. Промяна направена с идеята да се застигне изоставането на Nokia от Apple и Google в областта на смартфоните, продукт, който донякъде всъщност е отроче именно на Nokia. Да, по това време Nokia все още бе производител номер 1, но на устройства от доста по-ниския клас, залагаха основно на  количество. Но появата на iPhone и на по-късен етап на Android сериозно застраши позициите на финландците. Цените падат, а от другите получаваш много повече в един телефон, отколкото получаваш от Nokia. Нещо, което Стивън казва на служителите си чрез email в прав текст (цялото писмо може да се прочете тук):

In 2008, Apple’s market share in the $300+ price range was 25 percent; by 2010 it escalated to 61 percent. They are enjoying a tremendous growth trajectory with a 78 percent earnings growth year over year in Q4 2010. Apple demonstrated that if designed well, consumers would buy a high-priced phone with a great experience and developers would build applications. They changed the game, and today, Apple owns the high-end range.

And then, there is Android. In about two years, Android created a platform that attracts application developers, service providers and hardware manufacturers. Android came in at the high-end, they are now winning the mid-range, and quickly they are going downstream to phones under €100. Google has become a gravitational force, drawing much of the industry’s innovation to its core.

Let’s not forget about the low-end price range. In 2008, MediaTek supplied complete reference designs for phone chipsets, which enabled manufacturers in the Shenzhen region of China to produce phones at an unbelievable pace. By some accounts, this ecosystem now produces more than one third of the phones sold globally – taking share from us in emerging markets.

While competitors poured flames on our market share, what happened at Nokia? We fell behind, we missed big trends, and we lost time. At that time, we thought we were making the right decisions; but, with the benefit of hindsight, we now find ourselves years behind.

The first iPhone shipped in 2007, and we still don’t have a product that is close to their experience. Android came on the scene just over 2 years ago, and this week they took our leadership position in smartphone volumes. Unbelievable.

We have some brilliant sources of innovation inside Nokia, but we are not bringing it to market fast enough. We thought MeeGo would be a platform for winning high-end smartphones. However, at this rate, by the end of 2011, we might have only one MeeGo product in the market.

At the midrange, we have Symbian. It has proven to be non-competitive in leading markets like North America. Additionally, Symbian is proving to be an increasingly difficult environment in which to develop to meet the continuously expanding consumer requirements, leading to slowness in product development and also creating a disadvantage when we seek to take advantage of new hardware platforms. As a result, if we continue like before, we will get further and further behind, while our competitors advance further and further ahead.

За всички е ясно, че Nokia са 4 години зад тренда и конкуренцията, така че Elop решава, че имат нужда от бързи резултати. В писмото се говори за успехите на iPhone и Android, и се очаква MeeGo като с магическа пръчка да е готов за една година. Elop дали се е поинтересувал, колко време е замислян и разработван iPhone. Дори и първият телефон с Android не може да се нарече кой знае какъв успех, докато не излязоха моделите на HTC и Samsung да го подкрепят. MeeGo имаше бъдеще (и все още го има), но Nokia решиха да заложат на WP7, толкова по-зле за тях. Предполагам, някой ще си помисли, че хейтът по Nokia е нормална реакция за феновете на open source. Но изглежда, че не само те мислят така. Доста анализатори отчитат прилягането на Nokia на M$ като грешка. Бизнеса изглежда също е на това мнение, 16% спад на акциите само за ден, не може да значи нещо друго. Какви всъщност бяха опциите пред Nokia:

• да следва предварително обявения план от миналата година – Symbian за low-end устройствата, и MeeGo за смартфони
• да заложи на Android (може би дори на WebOS)
• да заложи на Microsoft – въпреки слуховете в последната седмица, едва ли някой всъщност го е очаквал

Безспорно от „сватбата“ не печели Nokia. С един удар да затриеш два проекта, в които е вложен толкова много труд и да заложиш на операционна система, която никак не е на почит сред мобилните у-ва е меко казано странно. От тази сделка, Nokia може само да загуби (както са губили и други преди това), а Microsoft може само да спечели. Ако стане добре дошло, ако не…какво им пука. И в този ред на мисли, CEO-то на Nokia все още държи доста солиден дял акции на Microsoft.

Защо всъщност пиша всичко това. Отговорът е прост, защото съм разочарован – наистина очаквах много от MeeGo и възможността за телефон с Qt. Защото има нужда от конкуренция за Android. А и защото съчувствам на хората, които са вложили доста работа и в двата проекта, а на края получават нож в гърба. За съжаление в бизнеса, няма място за принципи и романтика.

Това, все пак вдъхва някакви надежди:

“The Linux Foundation is disappointed in Nokia’s decision today to choose Microsoft as the primary platform for its mobile phones. Tough times give birth to difficult decisions that we don’t always agree with, but open source is — at its core — about choice. We believe that open source software is more than a sum of its parts, and the market is currently bearing that out. The Linux Foundation is here to enable collaboration among its members and the Linux community, and we invite participation in MeeGo and any of our other many projects and programs. In its 20th anniversary year, Linux is a significant underpinning in every computing segment. Full steam ahead.”

Топологията от моята страна, която в случая е client е следната:
client side: LAN –> linux gateway –> Cisco Router
Топологията от среща:
ISP –> linux gateway –> servers (public IPs) (static routing)

Какво проверих:
client side:

• смяна на ftp client-a – Тествах  upload с ncftp, curl, netcat – без никаква промяна, проблема беше налице
• active / passive ftp – всеки, който е пускал FTP server и е имал клиенти зад NAT, знае че това е един от най-често срещаните проблеми – Но моят проблем, не зависеше от това
• upload от друга машина с публично IP, която не е зад локалния linux gateway (за да избегна NAT-a) – проблемът все още си е налице
• upload със спрян SACK – Петър Пенчев направи добро предложение в twitter – но и това не помогна
• upload с промяна на keepalive – търсене в Google за подобни проблеми ме доводе до този пост в serverfault и съответно си поиграх с tcp keepalives – но отново без успех
• upload при по-ниско MTU – друг често срещан проблем с MTU / PMTU-D – промяна на стойностите от моя страна отново не доведе до успех
• upload от мрежи на други доставчици, до които имам достъп – мина без проблеми. На по-късен етап се оказа, че съм се заблудил (ще опиша защо малко по-надолу)
• download на файл от сървъра – без проблеми
• upload от самия cisco router – единственото у-во, което не бях проверил от моя страна бе cisco router-а, за това пробвах upload и от него – успешно upload-нах IOS файла.

Едновременно с това, накарах няколко приятели и познати администратори да тестват и от техни мрежи. Някои успяха да upload-нат файл, други не. Така че, въпреки успеха от рутера, нямаше логика проблема да е в него. Хората, които също не успяха да upload-нат файлове на FTP сървъра нямаха в мрежите си Cisco рутери. Освен това upload до други 10 ftp server-а от моя страна протичаха без никакъв проблем.

server side:

• смяна на ftp server-a (pure-ftpd, vsftpd) – проблемът си остана
• firewall – passive / active проблеми от страна на сървъра, спиране на филтрация по IP, отваряне на портове за passive mode и т.н., дори спиране на firewall-а – не доведе до никаква промяна
• промяна на idle time и timeout на връзките на ftp server-а също не доведе до никаква промяна.
• upload директно до машината която играе ролята на gateway за другите зад нея – проблемът беше налице и там
• пускане на ftp server-а на друг порт – без промяна
• на мрежовите интерфейси няма грешки или колизии
• download на същия файл обратно, т.е. сървъра е клиент – без проблеми, така че проблемът бе само и единствено с upload-а

Същевременно с това, всичко с други протоколи си бе наред – icmp, smtp, ssh (файлът се upload-ваше по scp без никакъв проблем). Реших да направя tcpdump да видя какво става. На пръв поглед нещата изглеждаха нормално, макар че личеше, че има проблем. Нещата протичаха по следния начин:

Last Fragment Lost –> TCP Dup –> TCP Fast Retransmission –> TCP Dup –> TCP Fast Retransmission –> TCP Out of Order –> TCP Tetransmission –> TCP Window Full –> Connection Timed Out

С оглед на всичко това, в крайна сметка нещата сочеха за проблем с мрежово устройство по пътя, който се проявява само за FTP. След като бях проверил всичко при мен, оставаше да звънна на доставчика. Преди това обаче реших да попитам и други хора, работещи в областта на мрежите. И така, колегите от HWBG ме насочиха към евентуален проблем с media converter.

Всичко изглеждаше логично, но ме глождеше едно, как така от някои мрежи успявам да upload-на файл. Ако проблемът в конвертора, то няма логика да работи избирателно. Това можеше да значи, че проблемът не е със самия конвертор на място, а някъде по пътя между мен и него, нормално от други мрежи пътя е друг и upload-а върви. Реших да направя няколко последни теста и установих, че по-рано съм направил грешно предположение. За съжаление не винаги ползвах един и същи тестов файл ( това би ми спестило един ден „блъскане“), но късметът не е бил на моя страна. Естествено, бях се сетил, че проблемът всъщност може да е във файла, но това че други хора също не успяваха да качат големи файлове, значеше, че проблемът не е в самия файл. Оказа се обаче, че проблемът съществува само за точно определени файлове/разширения:

• с големи .avi .zip .rar – всичко бе ОК
• с големи .iso .img .eps – проблемът бе налице

Това, а и факта, че upload-а спираше винаги на точно едно и също място, значеше че конверторите имат проблем с точно определени символи, вероятно заради data stuffing. Ето hexdump за отделните файлове.

• .img

Remote write failed after 18808832 bytes had been sent: Connection timed out.
hexdump -C -s 18808800 -n 128 -v rhinstall-stage2.img
011effe0  b3 d1 36 4c 4d 4d 7a 32  92 95 1c c4 93 8b 9f a2  |..6LMMz2........|
011efff0  6d 9b 9a 9c 4c e4 4e 76  f5 3e 7f 22 ff 9e d7 79  |m...L.Nv.>."...y|
011f0000  83 d7 a2 ed 9e 69 29 93  fd fd 7a 7e 3e e1 ff 78  |.....i)...z~>..x|
011f0010  3e a1 3e 9a 50 df 49 a8  ef 45 af 75 f3 bc 15 6d  |>.>.P.I..E.u...m|
011f0020  33 d5 c7 92 5e 7d a3 eb  fd ea d7 dc cd e7 bc 10  |3...^}..........|
011f0030  6d 6b e5 2f 45 db 96 a8  8d 68 3b ac a6 e3 97 ff  |mk./E....h;.....|
011f0040  c4 eb 60 ad f9 36 71 17  ab d9 c8 6e 0e 71 98 63  |..`..6q....n.q.c|
011f0050  5c e0 21 5e e0 79 f6 f3  3a 9f 72 0b cb 58 ce 0a  |\.!^.y..:.r..X..|
011f0060
 
hexdump -s 18808800 -n 128 -v rhinstall-stage2.img
11effe0 d1b3 4c36 4d4d 327a 9592 c41c 8b93 a29f
11efff0 9b6d 9c9a e44c 764e 3ef5 227f 9eff 79d7
11f0000 d783 eda2 699e 9329 fdfd 7e7a e13e 78ff
11f0010 a13e 9a3e df50 a849 45ef 75af bcf3 6d15
11f0020 d533 92c7 7d5e eba3 eafd dcd7 e7cd 10bc
11f0030 6b6d 2fe5 db45 a896 688d ac3b e3a6 ff97
11f0040 ebc4 ad60 36f9 1771 d9ab 6ec8 710e 6398
11f0050 e05c 5e21 79e0 f3f6 9f3a 0b72 58cb 0ace
11f0060

hexdump -C -s 26968000 -n 128 -v rhinstall-stage2.img
019b7fc0  2c 3d 2c 03 2c 23 2c 13  2c 33 2c 0b 2c 2b 2c 1b  |,=,.,#,.,3,.,+,.|
019b7fd0  2c 3b 2c 07 2c 27 2c 17  2c 37 2c 0f 2c 2f 2c 1f  |,;,.,',.,7,.,/,.|
019b7fe0  2c 3f ac 00 ac 20 ac 10  ac 30 ac 08 ac 28 ac 18  |,?... ...0...(..|
019b7ff0  ac 38 ac 04 ac 24 ac 14  ac 34 ac 0c ac 2c ac 1c  |.8...$...4...,..|
019b8000  ac 3c ac 02 ac 22 ac 12  ac 32 ac 0a ac 2a ac 1a  |.<..."...2...*..|
019b8010  ac 3a ac 06 ac 26 ac 16  ac 36 ac 0e ec 5f 58 5d  |.:...&...6..._X]|
019b8020  58 3d 58 7d 58 03 58 43  58 23 58 63 58 13 58 53  |X=X}X.XCX#XcX.XS|
019b8030  58 33 58 73 58 0b 58 4b  58 2b 58 6b 58 1b 58 5b  |X3XsX.XKX+XkX.X[|
019b8040
 
hexdump -s 18808800 -n 128 -v rhinstall-stage2.img
11effe0 d1b3 4c36 4d4d 327a 9592 c41c 8b93 a29f
11efff0 9b6d 9c9a e44c 764e 3ef5 227f 9eff 79d7
11f0000 d783 eda2 699e 9329 fdfd 7e7a e13e 78ff
11f0010 a13e 9a3e df50 a849 45ef 75af bcf3 6d15
11f0020 d533 92c7 7d5e eba3 eafd dcd7 e7cd 10bc
11f0030 6b6d 2fe5 db45 a896 688d ac3b e3a6 ff97
11f0040 ebc4 ad60 36f9 1771 d9ab 6ec8 710e 6398
11f0050 e05c 5e21 79e0 f3f6 9f3a 0b72 58cb 0ace
11f0060

• .eps

hexdump -C -s 46497764 -n 128 -v BACB-Standard-170x230.eps
02c57fe4  f8 20 f8 f8 f8 20 f8 f8  f8 f8 f8 f8 f8 f8 f8 f8  |. ... ..........|
02c57ff4  f8 f8 f8 f8 f8 f8 f8 f8  f8 27 f8 f8 f8 27 f8 f8  |.........'...'..|
02c58004  f8 27 f8 f8 f8 20 f8 f8  f8 04 f8 f8 f8 26 f8 f8  |.'... .......&..|
02c58014  f8 26 f8 f8 f8 04 f8 f8  f8 05 f8 04 f8 27 f8 f8  |.&...........'..|
02c58024  f8 26 f8 f8 f8 05 f8 f8  f8 27 f8 f8 f8 27 f8 f8  |.&.......'...'..|
02c58034  f8 f8 f8 f8 f8 26 f8 04  f8 27 f8 f8 f8 04 f8 f8  |.....&...'......|
02c58044  f8 f8 f8 f8 f8 f8 f8 f8  f8 f8 f8 f8 f8 f8 f8 f8  |................|
02c58054  f8 f8 f8 f8 f8 f8 f8 f8  f8 f8 f8 f8 f8 f8 f8 f8  |................|
02c58064
 
hexdump -s 46497764 -n 128 -v BAC-170x230.eps
2c57fe4 20f8 f8f8 20f8 f8f8 f8f8 f8f8 f8f8 f8f8
2c57ff4 f8f8 f8f8 f8f8 f8f8 27f8 f8f8 27f8 f8f8
2c58004 27f8 f8f8 20f8 f8f8 04f8 f8f8 26f8 f8f8
2c58014 26f8 f8f8 04f8 f8f8 05f8 04f8 27f8 f8f8
2c58024 26f8 f8f8 05f8 f8f8 27f8 f8f8 27f8 f8f8
2c58034 f8f8 f8f8 26f8 04f8 27f8 f8f8 04f8 f8f8
2c58044 f8f8 f8f8 f8f8 f8f8 f8f8 f8f8 f8f8 f8f8
2c58054 f8f8 f8f8 f8f8 f8f8 f8f8 f8f8 f8f8 f8f8
2c58064

• .iso

hexdump -C -s 163800 -n 128 -v ADRIANE-KNOPPIX_V6.2.1CD-2010-01-31-EN.iso
00027fd8  06 3a 66 27 c1 d2 6a 21  b9 6e fa 2f a1 70 24 79  |.:f'..j!.n./.p$y|
00027fe8  1e 35 01 a1 b5 99 04 e0  60 05 6a 05 0e 8c b6 1d  |.5......`.j.....|
00027ff8  05 28 50 63 1b 45 48 6c  38 01 c1 8c 5d 26 0e aa  |.(Pc.EHl8...]&..|
00028008  01 14 60 6e 64 23 06 a5  20 a9 3b 1e 9d 11 e9 10  |..`nd#.. .;.....|
00028018  b6 28 ec dc c0 59 0f 3d  e8 c6 70 f7 26 20 5c 8d  |.(...Y.=..p.& \.|
00028028  ff 03 2b e8 ab 17 86 58  08 b4 37 00 73 ac d1 40  |..+....X..7.s..@|
00028038  0b 1f 83 35 84 36 6d 68  41 56 d5 1f e8 fe f6 51  |...5.6mhAV.....Q|
00028048  8a ac 6c 7e 55 1d b7 ef  0e 26 7d c8 d0 16 cd be  |..l~U....&}.....|
00028058
 
hexdump -s 163800 -n 128 -v ADRIANE-KNOPPIX_V6.2.1CD-2010-01-31-EN.iso
0027fd8 3a06 2766 d2c1 216a 6eb9 2ffa 70a1 7924
0027fe8 351e a101 99b5 e004 0560 056a 8c0e 1db6
0027ff8 2805 6350 451b 6c48 0138 8cc1 265d aa0e
0028008 1401 6e60 2364 a506 a920 1e3b 119d 10e9
0028018 28b6 dcec 59c0 3d0f c6e8 f770 2026 8d5c
0028028 03ff e82b 17ab 5886 b408 0037 ac73 40d1
0028038 1f0b 3583 3684 686d 5641 1fd5 fee8 51f6
0028048 ac8a 7e6c 1d55 efb7 260e c87d 16d0 becd
0028058

Вече беше 100% сигурно, че проблемът е в конвертор. Оставаше да намерим кой. След съдействие от страна на доставчика подменихме първо този на място. Разлика нямаше. След това дойде ред и на този преди него, и воала. Всичко вече работи както трябва.

Ако все още не сте гледали филма, то се смятайте за предупредени, защото след постера има Спойлери.

Честно казано, когато излезе първият трейлър не бях толкова очарован. Дори (тъй като не познавах оригинала) се чудех на целия шум. Следващите трейлъри обаче ме грабнаха. Може би направих грешка че попрочетох някое друго ревю преди да ида да го гледам и изглежда попаднах в капана на свръхочакванията. За това и останах с впечатлението, че на филма нещо му липсваше, не ме грабна както очаквах. Това съвсем не означава, че не ми е харесал, дори напротив. Визуалните ефекти, както всеки може да предположи дори от трейлърите са изключителни. Саундтрака в допълнение към тях също. Хареса ми и Olivia Wilde (позната като 13 от House M.D.) в едно доста интересно и различно амплоа, в което бих казал че се справи много добре. Но нещото, което ме грабна най-много е използването на няколко реални unix команди. И това е и нещото, за което ще напиша малко повече.

Нека започнем с това, че очевидно и Kevin Flynn, и синът му Sam са фенове на свободния софтуер. Да проникнеш в собствената си компания, за да откраднеш новата версия на операционната система, която трябва да излезе на пазара и да я пуснеш онлайн е доста показателно и същевременно е интересен намек към някои компании :)

Точно в този момент е ѝ първата поява на Unix команда, за съжаление не си спомням, какво точно написа авторът на новата 12-та версия на Flynn OS. След това обаче, когато Sam отива в скривалището на баща си и намира прашасалата му конзола, виждаме следното:

клик за по-голям размер

Очевидно изход от командата top, който показва, че има 2-ма users и uptime от 9 дни (което малкo не се връзва и е една от грешките, във филма, които забелязах), 2GB RAM и 4GB Swap . Изглежда всички приложения са стартирани като root :),спокойно се виждат watchdog и ksoftirqd (който се появява за пръв път в ядро 2.3.15 през 2000г.). Сякаш има и отворен текстов редактор (навява асоциации на vi), Интересно е, че се ползва touch screen. След като позабърсва прахта, Sam използва последователно „whoami„, „uname -a“ и history, след което стартира приложението, което задейства лазера и се озовава в „Мрежата“. Изхода от uname връща Solar OS 4.0.1, с generic kernel, а машината е с i386 процесор (Solar OS 4.0.1 Generic_50203….um4 i386 Unknown.Unknown). Та хората от Sun, които загиват под крилото на Oracle може би трябва да се чувства горди :) Вижда се, че има и два sata диска – sda и sdb, каквито определено е нямало през 80-тте, когато би трябвало да  е произведена въпросната машина. Та така, в общи линии използването на реални unix команди ме зарадва много, но както се вижда не са изпипали всичко в детайли :)

Оценка: 7/10

Снимки: wikip(m)edia, Victor Ruiz @ flickr