Kannel daily svn snapshot rpm

петък, октомври 28th, 2011

Currently the current kannel version in epel is 1.4.3 /which according to kannel.org is the latest stable release/. However if you want to use sqlbox and smppbox, the only option is to use svn. So I decided to build my custom kannel rpm by using the source tarball from the daily svn snapshot. My kannel.spec is based on the file from the epel rpm for 1.4.3 version. The changes are minimal:

--- 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

Default to open: The story of open source and Red Hat

вторник, август 30th, 2011

Какво се случва с CentOS?

четвъртък, юли 28th, 2011

Това е въпрос, който доста хора избрали тази дистрибуция си задаваха докато чакаха излизането на CentOS 6, което се забави повече от половин година след излизането на RHEL 6.0. Е, в крайна сметка го дочакахме – CentOS 6 стана факт на 10-ти юли. Каква обаче бе причината за това забавяне така и не стана ясно. Изписа се доста по темата,  както в специализираните Linux издания и форуми, така и в centos-devel мейл листа, както и по блогове на ползватели и разработчици, но до голяма степен повечето от казаното бяха догадки и предположения. Отдавна се каня да драсна и аз някои размисли по въпроса, та дойде и този светъл момент. Няма да се спирам подробно на това, как и защо е възникнал, или какво представлява CentOS. Просто ще напиша какво не ми хареса на мен в цялата история.

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

Разбира се основното е забавянето от 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“

Таблицата:

Release Version CentOS delay SL delay Oracle delay RHEL release date CentOS release date SL release date Oracle release date
4.4 20 60 77 08/10/06 08/30/06 10/09/06 10/26/06
4.5 16 55 16 05/01/07 05/17/07 06/25/07 05/17/07
4.6 30 117 24 11/16/07 12/16/07 03/12/08 12/10/07
4.7 51 41 12 07/24/08 09/13/08 09/03/08 08/05/08
4.8 95 71 8 05/18/09 08/21/09 07/28/09 05/26/09
4.9 14 64 8 02/16/11 03/02/11 04/21/11 02/24/11
5 28 51 104 03/14/07 04/12/07 05/04/07 06/26/07
5.1 25 70 19 11/07/07 12/02/07 01/16/08 11/26/07
5.2 34 36 12 05/21/08 06/24/08 06/26/08 06/02/08
5.3 69 58 8 01/20/09 03/31/09 03/19/09 01/28/09
5.4 49 63 7 09/02/09 10/21/09 11/04/09 09/09/09
5.5 44 49 7 03/31/10 05/14/10 05/19/10 04/07/10
5.6 85 159 9 01/13/11 04/08/11 06/21/11 01/22/11
6 242 113 93 11/10/10 07/10/11 03/03/11 02/11/11
6.1 60 60 13 05/19/11 TBD TBD 06/01/11

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

От друг ъгъл и с малко 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.

CentOS 6.0 remote install via VNC

петък, юли 15th, 2011

Отдавна ми предстоеше една нова инсталация, но реших да изчакам излизането на CentOS 6. Голямо чакане падна, но в началото на седмицата чудото се случи. А днес успях да отделя и време за въпросната машина. За да не я вземам при мен, реших да заложа на netinstall директно в сървърното, но за съжаление Anaconda нещо не се разбра с конзолата на ATEN. Не ми се занимаваше да debug-вам какъв е проблема, a и нямаше как да ползвам text install понеже в CentOS 6 той е доста орязан и не може да се правят следните неща:

  • configuring advanced storage methods such as LVM, RAID, FCoE, zFCP, and iSCSI.
  • customizing the partition layout
  • customizing the bootloader layout
  • selecting packages during installation
  • configuring the installed system with firstboot
По този начин се наложи да се насоча към друг вариант – отдалечена инсталация посредством VNC, опция която е възможна с Anaconda. За тази цел обаче е нужно да имаме текущо инсталирана операционна система на машината, на която искаме да инсталираме. За мое щастие аз имах. И така:
  • Логваме се на машината и сваляме initrd и vmlinuz за новата версия, в случая 6.
cd /boot
curl http://centos.skknet.net/6.0/os/i386/images/pxeboot/vmlinuz -o vmlinuz.centos6.pxe
curl http://centos.skknet.net/6.0/os/i386/images/pxeboot/initrd.img -o initrd.img.centos6.pxe

Разбира се, може да използваме и друг произволен CentOS mirror. Както и x86_64 вместо i386, ако искаме да инсталираме 64bit версия на CentOS.

  • Update-ваме Grub (/boot/grub/menu.lst).
title Centos Remote Install (PXE)
root (hd0,0)
kernel /vmlinuz.centos6.pxe vnc vncpassword=PASSWD headless ip=IPADDR netmask=NETMASK gateway=GATEWAYIP dns=8.8.8.8 ksdevice=eth0 method=http://centos.skknet.net/6.0/os/i386 lang=en_US keymap=us
initrd /initrd.img.centos6.pxe

Където:

vnc
vncpassword={парола за достъп до vnc сървъра, не по-малка от 6 символа}
headless
ip={IP адрес на отдалечената машина}
netmask={мрежова маска на отдалечената машина}
gateway={default gateway на отдалечената машина}
dns={IP адрес на DNS сървъра}
ksdevice={използваният мрежов интерфейс}
method={URL до директорията съдържаща images/install.img}
lang={proper language code}
keymap={proper country code}

Трябва да се има предвид обаче, че настройките по-горе са специфични в зависимост от текущата инсталация, наличието на отделен /boot дял, естествено IP адреса и default GW, мрежовия интерфейс, дали линка към посочения mirror е активен и т.н.

  • Ако сме се уверили, че всичко това е наред, остава само да рестартираме машината:
shutdown -r now
  • Остава само да се свържем към нея:
vncviewer IPADDR:1

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

1. Redhat Magazine
2. Redhat Installation Guide

Pure-Ftpd и pure-uploadscript

сряда, декември 15th, 2010

Когато опре до пускане на ftp server с virtual users vsftpd не е първи избор, особено ако искаме sql backend. По тази причина, а и заради някои други благини моят избор в такива случаи пада върху pure-ftpd. Една от въпросните благини е pure-uploadscript, която за да не преразкавам, прави следното:

If Pure-FTPd is compiled with –with-uploadscript (default in binary distributions), and if the -o (or –uploadscript) is passed to the server, a named pipe called /var/run/pure-ftpd.upload.pipe is created. You will also notice an important file called /var/run/pure-ftpd.upload.lock, used for locking.
After a successful upload, the file name is written to the pipe.
pure-uploadscript reads this pipe to automatically run any program or script to process the newly uploaded file.

When the upload script is run, the name of the newly uploaded file is the first argument passed to the script (referenced as $1 by most shells) . Some environment variables are also filled by useful info about the file. UPLOAD_SIZE The size of the file, in bytes. UPLOAD_PERMS The permissions, as an octal integer. UPLOAD_UID The numerical UID of the owner. UPLOAD_GID The numerical GID of the owner. UPLOAD_USER The login of the owner. UPLOAD_GROUP The group name the files belongs to. UPLOAD_VUSER The full user name, or the virtual user name (127 chars max) .

Което е нещо доста полезно. Реално не е много трудно да се напише някой скрипт, който би правил същото. Но защо, след като го има имплементирано. Ползвал съм въпросната функция често пъти, например за да се изпрати mail с известие за качени файлове от даден потребител, или пък да се извърши последваща обработка.

Съществува обаче един проблем, който вече на два пъти ме тормози (а и не само мен). Да, като не си записвам нещо, което вече съм debug-нал, се налага да го debug-вам втори път. Именно това и инспирира този ми блог пост. За какво по-точно става дума. Pure-Ftpd по принцип идва без конфигурационен файл, въпреки че има такава опция и тя се ползва активно от дистрибуциите използващи пакетни мениджъри. Това всъщност не е от голямо значение в случая, но го споменавам защото аз по принцип ползвам такава. Първият път когато срещнах проблема, за който ще пиша по-долу всъщност беше под Slackware. Проблемът се проявява, ако човек пропусне ето тази забележка в README файла:

- ‘-o’: Write all uploaded files to ‘/var/run/pure-ftpd.upload.pipe’ so
that the ‘pure-uploadscript’ program can run. Don’t enable that option if
you don’t actually use ‘pure-uploadscript’ otherwise pure-ftpd will hang
waiting for pure-uploadscript to start.

Та хубаво е да се има предвид, че ако pure-ftpd бъде стартиран с ключ „-o“ то  чака pure-uploadscript да бъде стартиран, и ако не го намери, то се получава неприятна изненада. pure-ftpd не се оплаква, дори се вижда като процес, но реално зависва в очакване на pure-uploadscript. Според мен не е лошо това да се добави като коментар и в man-а или пък в секцията засягаща uploadscript в pure-ftpd.conf, въпреки че е изрично описано в README и във FAQ на сайта (ping-нах разработчиците по въпроса).

Та ако сме решили да ползваме pure-uploadscript, ще трябва да го стартираме сами, понеже:

For security purposes, the server never launches any external program. It’s why there is a separate daemon, that reads new uploads pushed into a named pipe by the server. Uploads are processed synchronously and sequencially.It’s why on loaded or untrusted servers, it might be a bad idea to use pure-uploadscript with lenghty or cpu-intensive scripts.

като имаме предвид следното:

IMPORTANT: YOU MUST START PURE-FTPD _FIRST_ and _THEN_ START PURE-UPLOADSCRIPT. THE REVERSE ORDER WON’T WORK.

За тази цел на базата на това си спретнах един скрипт, който да добавя в /etc/init.d/, като преди това е важно да се отбележат следните неща:

  • Приоритета на стартиране на pure-uploadscript трябва да е по-висок от този на init скрипта на pure-ftpd
  • „/usr/local/bin/uploadscript.sh“ е скрипт-а, който ще се изпълнява при успешен upload на файл /не се прави проверка, дали uploadscript.sh съществува/
  • не се прави проверка дали pure-uploadscript вече не е стартиран.
#!/bin/sh
#
# Startup script for the pure-ftpd pure-uploadscript
#
# chkconfig: - 90 10
# description: pure-upload script is a nice Pure-FTPD feature regarding \
# uploads. Any external program or script can be automatically called after a \
# successful upload. 
 
### BEGIN INIT INFO
# Provides:
# Required-Start:
# Required-Stop:
# Should-Start:
# Should-Stop:
# Default-Start:
# Default-Stop:
# Short-Description:
# Description:
### END INIT INFO
 
# Source function library.
. /etc/rc.d/init.d/functions
 
exec="/usr/sbin/pure-uploadscript"
prog="pure-uploadscript"
#call an external program or script after successfull upload
callscript="/usr/local/bin/uploadscript.sh"
 
[ -e /etc/sysconfig/$prog ] && . /etc/sysconfig/$prog
 
lockfile=/var/lock/subsys/$prog
 
start() {
 # Make sure the pure-ftpd is running
if [ ! -e /var/lock/subsys/pure-ftpd ]; then
        echo $"Pure-FTPd is not running - exiting"
        exit 1
fi
    [ -x $exec ] || exit 5
    echo -n $"Starting $prog: "
    daemon $exec -B -r $callscript
    retval=$?
    echo
    [ $retval -eq 0 ] && touch $lockfile
    return $retval
}
 
stop() {
    echo -n $"Stopping $prog: "
    killproc $prog
    retval=$?
    echo
    [ $retval -eq 0 ] && rm -f $lockfile
    return $retval
}
 
restart() {
    stop
    start
}
 
reload() {
    restart
}
 
force_reload() {
    restart
}
 
rh_status() {
    status $prog
}
 
rh_status_q() {
    rh_status > /dev/null 2>&1
}
 
case "$1" in
    start)
        rh_status_q && exit 0
        $1
        ;;
    stop)
        rh_status_q || exit 0
        $1
        ;;
    restart)
        $1
        ;;
    reload)
        rh_status_q || exit 7
        $1
        ;;
    force-reload)
        force_reload
        ;;
    status)
        rh_status
        ;;
    condrestart|try-restart)
        rh_status_q || exit 0
        restart
        ;;
    *)
        echo $"Usage: $0 {start|stop|status|restart|condrestart|try-restart|reload|force-reload}"
        exit 2
esac
exit $?

Понеже изглежда, че WP-Syntax има собствено мнение относно визуализацията на „&&“ и „>“ то скрипта може да бъде свален и направо от тук.

Stop ACTA