Work « JustNick's Corner

Domains Expiration Script

вторник, февруари 22nd, 2011

Понеже ми се събраха доста домейни под моя юрисдикция, някои от които регистрирани преди доста време се огледах за shell script, който проверява за изтичането на даден домейн. Можеше да си играя да пиша и сам, но след като има готови, които вършат работа нямаше нужда. Единственото, което трябваше да се направи е проверка и за .bg домейни. Скриптът, който ползвах за основа може да бъде намерен тук /като цяло cyberciti.biz е чуден блог за unix/linux tips & tricks/

Кодът, който съм добавил е съобразен с 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}" &gt; ${WHOIS_TMP}
+     elif [ "${TLDTYPE}"  == "bg" ]; # Bulgaria
+     then
+         ${WHOIS} -h "whois.register.bg" "${1}" &gt; ${WHOIS_TMP}
      elif [ "${TLDTYPE}"  == "uk" ]; # United Kingdom
      then
          ${WHOIS} -h "whois.nic.uk" "${1}" &gt; ${WHOIS_TMP}
***************
*** 265,270 ****
--- 268,276 ----
      elif [ "${TLDTYPE}" == "jp" ];
      then
          REGISTRAR=`cat ${WHOIS_TMP} | ${AWK} '/Registrant/ &amp;&amp; $2 != ""  { REGISTRAR=substr($2,1,17) } END { print REGISTRAR }'`
+     elif [ "${TLDTYPE}" == "bg" ];
+     then
+         REGISTRAR=`cat ${WHOIS_TMP} | ${AWK} '/REGISTRANT:/ &amp;&amp; $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.

22.02.2011 Linux, Work 2 Comments

FTP upload – connection timed out

сряда, февруари 9th, 2011

Миналата седмица се сблъсках с много интересен проблем. Всичко започна тривиално. Трябваше да осигуря ftp достъп за клиент. Имам си изграден навик да проверявам дали всичко работи след като създам акаунта, защото ми се е случвало да забравям по нещо (я права на директория, я нещо друго). Логнах се с акаунта на клиента, upload-нах няколко pdf-а, които ми бяха под ръка – всичко бе наред. Не знам защо този път реших да upload-на и някой по-голям файл, по стечение на обстоятелствата бях в / и тръгнах да upload-вам rhinstall-stage2.img. В началото всичко изглеждаше наред, но след 18MB скоростта започна да пада прогресивно, и в края последва connection timed out. Първоначално помислих, че е имало някакъв проблем по трасето, но след повторен опит, нещата бяха същите. И така започнах да отмятам възможни проблеми един по един.

Топологията от моята страна, която в случая е 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.&gt;."...y|
011f0000  83 d7 a2 ed 9e 69 29 93  fd fd 7a 7e 3e e1 ff 78  |.....i)...z~&gt;..x|
011f0010  3e a1 3e 9a 50 df 49 a8  ef 45 af 75 f3 bc 15 6d  |&gt;.&gt;.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  |.&lt;..."...2...*..|
019b8010  ac 3a ac 06 ac 26 ac 16  ac 36 ac 0e ec 5f 58 5d  |.:...&amp;...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  |.'... .......&amp;..|
02c58014  f8 26 f8 f8 f8 04 f8 f8  f8 05 f8 04 f8 27 f8 f8  |.&amp;...........'..|
02c58024  f8 26 f8 f8 f8 05 f8 f8  f8 27 f8 f8 f8 27 f8 f8  |.&amp;.......'...'..|
02c58034  f8 f8 f8 f8 f8 26 f8 04  f8 27 f8 f8 f8 04 f8 f8  |.....&amp;...'......|
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...]&amp;..|
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.&amp; \.|
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....&amp;}.....|
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% сигурно, че проблемът е в конвертор. Оставаше да намерим кой. След съдействие от страна на доставчика подменихме първо този на място. Разлика нямаше. След това дойде ред и на този преди него, и воала. Всичко вече работи както трябва.

09.02.2011 Linux, Work No Comments

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 ] &amp;&amp; . /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 ] &amp;&amp; touch $lockfile
    return $retval
}
 
stop() {
    echo -n $"Stopping $prog: "
    killproc $prog
    retval=$?
    echo
    [ $retval -eq 0 ] &amp;&amp; rm -f $lockfile
    return $retval
}
 
restart() {
    stop
    start
}
 
reload() {
    restart
}
 
force_reload() {
    restart
}
 
rh_status() {
    status $prog
}
 
rh_status_q() {
    rh_status &gt; /dev/null 2&gt;&amp;1
}
 
case "$1" in
    start)
        rh_status_q &amp;&amp; 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 има собствено мнение относно визуализацията на „&&“ и „>“ то скрипта може да бъде свален и направо от тук.

15.12.2010 Linux, Work No Comments

Devotion to Duty

понеделник, февруари 22nd, 2010

cc (xkcd)

22.02.2010 Fun, Work 2 Comments

Нова опция в yum – history

неделя, декември 13th, 2009

Когато в предишното си писание споменах за проблемите покрай PackageKit, за които се шумеше при излизането на Fedora 12, много хора се питаха как никой от хората ползвали Rawhide не е забелязал такава промяна. Отговорът е прост. Никой (в това число и аз) не ползва графични инструменти от подобен род, когато имаш yum.

Някъде някой беше казал (за съжаление не си спомням, къде съм го прочел), че всяка себеуважаваща се съвременна дистрибуция трябва да има добър пакетен мениджър. За Redhat дериватите това е yum. Няма да се спирам на историята на проекта, но не мога да не спомена, че е изминат дълъг път от началото, и че постоянно става все по-добър. Разбира се, има и някои минуси (за мен лично, основно свързани с бързината), но след като в миналата версия бе представен yum-presto (delta rpms), то във Fedora 12 и съответната нова версия на yum (3.2.25), вече имаме yum history. Нещо, което предполагам доста администратори а и потребители безспорно ще оценят, и нещо, от което мисля, че наистина имаше нужда.

Какво се получаваше преди yum history? Инсталираме даден пакет, който има дадени зависимости, които също се инсталират покрай него. По някаква причина решаваме, че нямаме нужда от въпросната програма и я премахваме. Не всички dependencies инсталирани заедно с нея, винаги се премахват обаче. Какво ни дава history?

Дава ни възможността да се върнем една стъпка назад (undo) и да инсталираме или премахнем, това, което сме инсталирали или премахнали преди това. Получи се малка тафтология, но мисля, че с примерите по-долу нещата ще се изяснят. Възможните опции са: yum history info|list|summary|undo|redo|new

Ето ги и примерите:

[root@Pegasus ~]# yum history
Loaded plugins: allowdowngrade, fastestmirror, presto, protectbase, refresh-packagekit, security
ID     | Login user             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
6 |  Nick                | 2009-12-13 00:52 | Install        |    1
5 |  Nick                | 2009-12-13 00:48 | Install        |    4
4 |  Nick                | 2009-12-12 12:02 | Install        |    2
3 |  Nick                | 2009-12-12 11:43 | Install        |    8
2 |  Nick                | 2009-12-12 11:29 | Install        |    2
1 |  Nick                | 2009-12-12 11:20 | E, I, U        |   77

Ако искаме да видим точно определена транзакция, то изпълняваме yum history info ID:

[root@Pegasus ~]# yum history info 2
Loaded plugins: allowdowngrade, fastestmirror, presto, protectbase, refresh-packagekit, security
Transaction ID : 2
Begin time     : Sat Dec 12 11:29:54 2009
Begin rpmdb    : 1968:ab76e09445bc9332ee617c5c7bf34a9859e04ade
End time       :            11:30:01 2009 (7 seconds)
End rpmdb      : 1970:c33229c535f6633f7b1ee91e1461fb56c9784e64
User           :
Return-Code    : Success
Transaction performed with:
    Installed    rpm-4.7.1-6.fc12.x86_64
    Installed    yum-3.2.25-1.fc12.noarch
    Installed    yum-plugin-fastestmirror-1.1.24-2.fc12.noarch
Packages Altered:
    Install      kmod-nvidia-190.42-1.fc12.8.x86_64
    Dep-Install  kmod-nvidia-2.6.31.6-166.fc12.x86_64-190.42-1.fc12.8.x86_64

Ако искаме да премахнем промените направени от въпросната транзакция, то изпълняваме yum history undo ID:

[root@Pegasus ~]# yum history undo 2
Loaded plugins: allowdowngrade, fastestmirror, presto, protectbase, refresh-packagekit, security
Determining fastest mirrors
 * fedora: fedora.linuxman.biz
 * rpmfusion-free: ftp.upjs.sk
 * rpmfusion-free-updates: ftp.upjs.sk
 * rpmfusion-nonfree: ftp.upjs.sk
 * rpmfusion-nonfree-updates: ftp.upjs.sk
rpmfusion-free-updates                                                                                                                                       | 3.3 kB     00:00
rpmfusion-nonfree-updates                                                                                                                                    | 3.3 kB     00:00
updates                                                                                                                                                      | 4.4 kB     00:00
0 packages excluded due to repository protections
Undoing transaction 2, from Sat Dec 12 11:29:54 2009
    Install      kmod-nvidia-190.42-1.fc12.8.x86_64
    Dep-Install  kmod-nvidia-2.6.31.6-166.fc12.x86_64-190.42-1.fc12.8.x86_64
Resolving Dependencies
--&gt; Running transaction check
---&gt; Package kmod-nvidia.x86_64 0:190.42-1.fc12.8 set to be erased
---&gt; Package kmod-nvidia-2.6.31.6-166.fc12.x86_64.x86_64 0:190.42-1.fc12.8 set to be erased
--&gt; Finished Dependency Resolution
 
Dependencies Resolved
 
====================================================================================================================================================================================
 Package                                                       Arch                            Version                                     Repository                          Size
====================================================================================================================================================================================
Removing:
 kmod-nvidia                                                   x86_64                          190.42-1.fc12.8                             installed                           0.0
 kmod-nvidia-2.6.31.6-166.fc12.x86_64                          x86_64                          190.42-1.fc12.8                             installed                           11 M
 
Transaction Summary
====================================================================================================================================================================================
Remove        2 Package(s)
Reinstall     0 Package(s)
Downgrade     0 Package(s)
 
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Erasing        : kmod-nvidia-190.42-1.fc12.8.x86_64                                                                                                                           1/2
  Erasing        : kmod-nvidia-2.6.31.6-166.fc12.x86_64-190.42-1.fc12.8.x86_64                                                                                                  2/2
 
Removed:
  kmod-nvidia.x86_64 0:190.42-1.fc12.8                                         kmod-nvidia-2.6.31.6-166.fc12.x86_64.x86_64 0:190.42-1.fc12.8
 
Complete!

Ако отново изпълним yum history list, ще видим, че това е създало нова транзакция:

[root@Pegasus ~]# yum history
Loaded plugins: allowdowngrade, fastestmirror, presto, protectbase, refresh-packagekit, security
ID     | Login user             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
     7 |  Nick                | 2009-12-13 13:05 | Erase          |    2
     6 |  Nick                | 2009-12-13 00:52 | Install        |    1
     5 |  Nick                | 2009-12-13 00:48 | Install        |    4
     4 |  Nick                | 2009-12-12 12:02 | Install        |    2
     3 |  Nick                | 2009-12-12 11:43 | Install        |    8
     2 |  Nick                | 2009-12-12 11:29 | Install        |    2
     1 |  Nick                | 2009-12-12 11:20 | E, I, U        |   77

и ако решим все пак да върнем нещата назад и да инсталираме отново Kmod-nvidia*, то има два начина да го направим – yum history undo 7, или yum history redo 2:

[root@Pegasus ~]# yum history undo 7
Loaded plugins: allowdowngrade, fastestmirror, presto, protectbase, refresh-packagekit, security
Loading mirror speeds from cached hostfile
 * fedora: fedora.linuxman.biz
 * rpmfusion-free: ftp.upjs.sk
 * rpmfusion-free-updates: ftp.upjs.sk
 * rpmfusion-nonfree: ftp.upjs.sk
 * rpmfusion-nonfree-updates: ftp.upjs.sk
0 packages excluded due to repository protections
Undoing transaction 7, from Sun Dec 13 13:05:43 2009
    Erase        kmod-nvidia-190.42-1.fc12.8.x86_64
    Erase        kmod-nvidia-2.6.31.6-166.fc12.x86_64-190.42-1.fc12.8.x86_64
Resolving Dependencies
--&gt; Running transaction check
---&gt; Package kmod-nvidia.x86_64 0:190.42-1.fc12.8 set to be updated
---&gt; Package kmod-nvidia-2.6.31.6-166.fc12.x86_64.x86_64 0:190.42-1.fc12.8 set to be updated
--&gt; Finished Dependency Resolution
 
Dependencies Resolved
 
====================================================================================================================================================================================
 Package                                                   Arch                        Version                                 Repository                                      Size
====================================================================================================================================================================================
Installing:
 kmod-nvidia                                               x86_64                      190.42-1.fc12.8                         rpmfusion-nonfree-updates                       29 k
 kmod-nvidia-2.6.31.6-166.fc12.x86_64                      x86_64                      190.42-1.fc12.8                         rpmfusion-nonfree-updates                      2.2 M
 
Transaction Summary
====================================================================================================================================================================================
Install       2 Package(s)
Upgrade       0 Package(s)
 
Total download size: 2.3 M

[root@Pegasus ~]# yum history redo 2
Loaded plugins: allowdowngrade, fastestmirror, presto, protectbase, refresh-packagekit, security
Loading mirror speeds from cached hostfile
 * fedora: fedora.linuxman.biz
 * rpmfusion-free: ftp.upjs.sk
 * rpmfusion-free-updates: ftp.upjs.sk
 * rpmfusion-nonfree: ftp.upjs.sk
 * rpmfusion-nonfree-updates: ftp.upjs.sk
0 packages excluded due to repository protections
Repeating transaction 2, from Sat Dec 12 11:29:54 2009
    Install      kmod-nvidia-190.42-1.fc12.8.x86_64
    Dep-Install  kmod-nvidia-2.6.31.6-166.fc12.x86_64-190.42-1.fc12.8.x86_64
Resolving Dependencies
--&gt; Running transaction check
---&gt; Package kmod-nvidia.x86_64 0:190.42-1.fc12.8 set to be updated
--&gt; Processing Dependency: kmod-nvidia-2.6.31.6-166.fc12.x86_64 &gt;= 190.42-1.fc12.8 for package: kmod-nvidia-190.42-1.fc12.8.x86_64
--&gt; Running transaction check
---&gt; Package kmod-nvidia-2.6.31.6-166.fc12.x86_64.x86_64 0:190.42-1.fc12.8 set to be updated
--&gt; Finished Dependency Resolution
 
Dependencies Resolved
 
====================================================================================================================================================================================
 Package                                                   Arch                        Version                                 Repository                                      Size
====================================================================================================================================================================================
Installing:
 kmod-nvidia                                               x86_64                      190.42-1.fc12.8                         rpmfusion-nonfree-updates                       29 k
Installing for dependencies:
 kmod-nvidia-2.6.31.6-166.fc12.x86_64                      x86_64                      190.42-1.fc12.8                         rpmfusion-nonfree-updates                      2.2 M
 
Transaction Summary
====================================================================================================================================================================================
Install       2 Package(s)
Upgrade       0 Package(s)
 
Total download size: 2.3 M

Ако искаме повече информация за даден пакет, то може да комбинираме някои от опциите. Да речем yum history summary kmod-nvidia, yum history list kmod-nvidia или yum history info kmod-nvidia ни дават следната информация:

[root@Pegasus ~]# yum history summary kmod-nvidia
Loaded plugins: allowdowngrade, fastestmirror, presto, protectbase, refresh-packagekit, security
Login user                 | Time                | Action(s)        | Altered
-------------------------------------------------------------------------------
 Nick                    | Last day            | E, I             |        4
 Nick                    | Last week           | Install          |        2

[root@Pegasus ~]# yum history list kmod-nvidia
Loaded plugins: allowdowngrade, dellsysidplugin2, fastestmirror, presto, protectbase, refresh-packagekit, security
ID     | Login user             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
     8 |  Nick                | 2009-12-13 13:11 | Install        |    2
     7 |  Nick                | 2009-12-13 13:05 | Erase         |    2
     2 |  Nick                | 2009-12-12 11:29 | Install        |    2

[root@Pegasus ~]# yum history info kmod-nvidia
Loaded plugins: allowdowngrade, dellsysidplugin2, fastestmirror, presto, protectbase, refresh-packagekit, security
Transaction ID : 8
Begin time     : Sun Dec 13 13:11:52 2009
Begin rpmdb    : 1983:4824469c95865c6b3a6548a690e9fd10f7b8d43a
End time       :            13:11:57 2009 (5 seconds)
End rpmdb      : 1985:dc98b76dd546e9edd76e8b5b8520f5f7a8c7d7c7
User           :  Nick
Return-Code    : Success
Transaction performed with:
    Installed    rpm-4.7.1-6.fc12.x86_64
    Installed    yum-3.2.25-1.fc12.noarch
    Installed    yum-plugin-fastestmirror-1.1.24-2.fc12.noarch
Packages Altered:
    Install      kmod-nvidia-190.42-1.fc12.8.x86_64
    Dep-Install  kmod-nvidia-2.6.31.6-166.fc12.x86_64-190.42-1.fc12.8.x86_64
-------------------------------------------------------------------------------
Transaction ID : 7
Begin time     : Sun Dec 13 13:05:43 2009
Begin rpmdb    : 1985:dc98b76dd546e9edd76e8b5b8520f5f7a8c7d7c7
End time       :            13:05:54 2009 (11 seconds)
End rpmdb      : 1983:4824469c95865c6b3a6548a690e9fd10f7b8d43a
User           :  Nick
Return-Code    : Success
Transaction performed with:
    Installed    rpm-4.7.1-6.fc12.x86_64
    Installed    yum-3.2.25-1.fc12.noarch
    Installed    yum-plugin-fastestmirror-1.1.24-2.fc12.noarch
Packages Altered:
    Erase        kmod-nvidia-190.42-1.fc12.8.x86_64
    Erase        kmod-nvidia-2.6.31.6-166.fc12.x86_64-190.42-1.fc12.8.x86_64
-------------------------------------------------------------------------------
Transaction ID : 2
Begin time     : Sat Dec 12 11:29:54 2009
Begin rpmdb    : 1968:ab76e09445bc9332ee617c5c7bf34a9859e04ade
End time       :            11:30:01 2009 (7 seconds)
End rpmdb      : 1970:c33229c535f6633f7b1ee91e1461fb56c9784e64
User           :  Nick
Return-Code    : Success
Transaction performed with:
    Installed    rpm-4.7.1-6.fc12.x86_64
    Installed    yum-3.2.25-1.fc12.noarch
    Installed    yum-plugin-fastestmirror-1.1.24-2.fc12.noarch
Packages Altered:
    Install      kmod-nvidia-190.42-1.fc12.8.x86_64
    Dep-Install  kmod-nvidia-2.6.31.6-166.fc12.x86_64-190.42-1.fc12.8.x86_64

Полезно, лесно и удобно!

13.12.2009 Linux, Work No Comments

Stay up-to-date via RSS!

Domains Expiration Script

FTP upload – connection timed out

Pure-Ftpd и pure-uploadscript

Devotion to Duty

Нова опция в yum – history

Follow me on Twitter!

BOFH Excuses

Блогове, които чета

Планети

Категории

Архиви

Етикети

май 2012
П	В	С	Ч	П	С	Н
« дек
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31