Valery's Mlog

Mindlog of a Freak

Archive for the ‘Administration’ Category

March 22nd, 2007 by Valery Dachev

BlogHub.org воскресе

След доста мъки по прехвърлянето и благодарение на упоритостта на krae и моя милост, BlogHub.org вече живее нов живот с малко орязана функционалност (временно е спряна регистрацията, както и пускането на trackbacks), при това на български. Блоговете и потребителите са налице и ще се радвам, ако научавам за всякакви проблеми/предложения/похвали/т.н. свързани със сайта. За повечето неща знам и тук ще очертая един кратък “Road Map”, горе-долу в реда, в който смятам да пускам нещата. Голяма част от тези работи ще станат реалност и за BgIT.net, доколкото се движат от един и същи софтуер. Та ето какво смятам да направя:

  1. Нов форум. – Смятам да пусна един форум (вероятно SMF), в който потребителите да споделят проблемите си, решенията си и новини покрай сайта;
  2. Нова версия. – Предстои обновяване до последната версия на софтуера придружено с малки поправки по базата (в encodings), за да не стане някой сакатлък;
  3. Малко допълнения. – Ще се опитам да добавя Spam Karma 2 като допълнително разширение, което да филтрира нови коментари за реклами, след което ще отпуша trackbacks;
  4. Разкарване на spam блогове. – В сайта има регистрирани известна част такива – нещо, което няма да бъде толерирано. Всички такива блогове ще бъдат изтривани безусловно;
  5. Изтриване на празни неактивни блогове – Регистрирани са сума неподдържани блогове, които не са пипани откак са регистрирани (което означава, че или са празни или съдържат само публикацията по подразбиране). Излишно е такива блогове да товарят базата, а и да дават терен на spam bots да пълнят с коментари. След този етап ще бъде включена отново регистрацията на блогове;
  6. Изтриване на spam коментари – Това вероятно ще е най-времеотнемащата задача. Ще се постарая да обходя публикациите с подозрително голям брой коментари и да видя кои са задръстени със spam коментари и ще ги разчистя. Появата на следващи такива, надявам се, ще бъде спряна от Spam Karma 2. Възможно е да се нуждая от помощ за тази задача, така че всеки мазохист(ка) е добре дошъл;
  7. Вкарване в ред на темите – В темите и на двата сайта в момента е някакъв хаос. Смятам да се опитам да оправя положението, най-малкото като направя screenshots на качествените теми, а тези с по-малки проблеми да оправя. Останалите ще пипам, ако ми остане време. Отново, всяка помощ ще е добре дошла.

Искам да отбележа, че списъкът нито е пълен, нито окончателен и предложения за всякакви допълнения/корекции към него са добре дошли.

February 22nd, 2007 by Valery Dachev

MySQL: Reducing ibdata1

If you use the InnoDB storage engine for (some of) your MySQL tables, you’ve probably already came across a problem with its default configuration. As you may have noticed in your MySQL’s data directory (in Debian/Ubuntu – /var/lib/mysql) lies a file called ‘ibdata1′. It holds almost all the InnoDB data (it’s not a transaction log) of the MySQL instance and could get quite big. By default this file has a initial size of 10Mb and it automatically extends. Unfortunately, by design InnoDB data files cannot be shrinked. That’s why DELETEs, TRUNCATEs, DROPs, etc. can’t will not reclaim the space used by the file. Instead any freed regions are marked as unused and can be used later. Theoretically speaking the file could reach the maximum size allowed by the filesystem if no limit is set in the my.cnf file (in Debian/Ubuntu it’s located in /etc/mysql/my.cnf). Guess what ? It’s not set by default. However you can configure your InnoDB engine as described MySQL’s Reference Manual. Additionally you can force the server to create an *.ibd for each newly created InnoDB table by using the ‘innodb_file_per_table‘ option (quite intuitive, huh ? :)).

Read the rest of this entry »

October 8th, 2006 by Valery Dachev

Shame or Lame ?

Преди няколко дни бях нагости, та видях егати изпълнението на един СОФийски ИнтЯрНЕТ доставчик, чието име няма да спомена. Та срещу 20 лв. техниците на доставчика решават, че ще решат много банален проблем – “две машини, един акаунт”. Клиентът не е длъжен да разбира от всичко и с готовност ръсва 20 лв. на техниците, че и още 40 лв., за да си купи от тях switch. Първата идея, която ми идва наум е, едната машина да стои постоянно включена с две мрежови карти и на нея (все пак е Windows XP) да работи Internet Connection Sharing. В тази схема не виждам къде е мястото на switch-а. Оказва се, че решението на техниците е малко по-различно и просто ме хвърли в ансамбъла. В този switch влизат кабелът от Интернета и по един кабел от всяка от двете машини. До тук добре. Само че техниците настройват слагат на двата компютъра един и същи IP адрес (и вероятно с един и същи MAC адрес) !!! Иначе изпълнението е елегантно направено, като кабелите са прекарани грижливо по ъглите и боднати в стената, a самият switch прилично застопорен в коридора със захранване идващо по мрежовия кабел от една от стаите… постарали са се хората. Оставаше и мозък да имат…

По-учудващото обаче в случая е, че нито един от двата Windows-а не се оплаква от наличието на друга машина със същия IP адрес в мрежата. Има даже някаква мрежа, макар и загубите да се увеличават главоломно. Не съм голям спец, но единственото ми обяснение е, че Windows XP няма навика, като получи пакет на някой TCP порт без да има отворена връзка на него, да игнорира този пакет, вместо да върне пакет с вдигнат RST флаг. Не знам всъщност дали трябва да е точно това поведението по RFC…

July 10th, 2006 by Valery Dachev

OCI8 LOB Patch

Само набързо… в последната версия (1.2.1) на OCI8 раз??ирението за PHP има бъг при четенето на LOB полета. Пускам patch-ът, който все още се намира само в CVS версията на пакета:

diff -u -r ext/oci8.old/oci8-1.2.1/oci8_lob.c ext/oci8/oci8-1.2.1/oci8_lob.c
--- ext/oci8.old/oci8-1.2.1/oci8_lob.c	2006-05-02 09:33:15.000000000 +0300
+++ ext/oci8/oci8-1.2.1/oci8_lob.c	2006-07-10 14:20:46.000000000 +0300
@@ -150,11 +150,16 @@
 {
 	php_oci_connection *connection = descriptor->connection;
 	ub4 length = 0;
+#if defined(HAVE_OCI_LOB_READ2)
+	oraub8 bytes_read, bytes_total = 0, offset = 0;
+	oraub8 requested_len = read_length; /* this is by default */
+	oraub8 chars_read = 0;
+#else
 	int bytes_read, bytes_total = 0, offset = 0;
 	int requested_len = read_length; /* this is by default */
-#if defined(HAVE_OCI_LOB_READ2)
-	int chars_read = 0, is_clob = 0;
+	int chars_read = 0;
 #endif
+	int is_clob = 0;

 	*data_len = 0;
 	*data = NULL;
July 9th, 2006 by Valery Dachev

Oracle Database 10g Express Edition под Linux

Ще си спестя въведението за това кои са Oracle и какъв го дирят в моя блог. Така се случи, че в рамките на една седмица си имам сериозно взимане-даване с техните продукти. Един от тях е Oracle Database 10g Express Edition. Етикетът “Express Edition” стои върху група от продукти предназначени основно за развойна и учебна дейност. Пакетът включва напълно функционална база. Поради целите, които си поставя този edition, софтуерът има някои ограничения (добра статия за това има на този адрес):

  • сървърът може да адресира максимум 1Гб памет;
  • сървърът може да работи само върху един процесор;
  • сървърът поддържа най-много една база данни (не схема !);
  • сървърът се разпростира на максимум 4Гб дисково пространство;

В крайна сметка, тези ограничения не са толкова фатални за повечето случаи. Особено ако става дума за не толкова натоварени web приложения. Това са и част от причините да ми се наложи да се занимавам с нещо подобно, въпреки антипатията си към Oracle по принцип. Сега спирам да разтягам локуми и започвам страшно накратко и стъпка по стъпка – така, както си го записвах, докато инсталирах:

  1. изтегляне на необходимите пакети:

    ЗA DEBIAN НА AMD64: Тъй като Oracle предоставят своята Express Edition база данни комипилирана само за 32-битова архитектура, apt-get не може да се оправи в случаите, когато първичната архитектура на опеарционната система е amd64. Затова тегленето и инсталирането на пакетите трябва да стане наръка. Отделно, трябва да бъдат изтеглени и 32-битовите glibc6 библиотеки (това е пакетът libc-i386), тъй като 32-битово приложение явно не може да използва (тези?) 64-битови библиотеки и обратно.

    ЗА RPM-БАЗИРАНИ ДИСТРИБУЦИИ: Вероятно се изисква допълнително инсталиране на libaio. Тук говоря наизуст, тъй като такава система нямам. Ще се радвам, ако някой изпатил сподели своя опит.

    • за DEB-базирани дистрибуции с apt-get:
      • в /etc/apt/sources.list се добавя реда:

        deb http://oss.oracle.com/debian/ unstable main non-free

      • изпълнява се командата:

        apt-get -d libaio oracle-xe

    • за DEB-базирани дистрибуции без apt-get:
      • от тук се изтегля libaio пакета;
      • от там се изтегля oracle-xe пакета;
    • за RPM-базирани дистрибуции:
  2. инсталиране на сървъра:
    • за DEB-базирани дистрибуции с apt-get:

      apt-get install oracle-xe

    • за DEB-базирани дистрибуции без apt-get:

      dpkg -i libaio_0.3.104-1_i386.deb
      dpkg -i oracle-xe_10.2.0.1-1.1_i386.deb

    • за DEB-базирани дистрибуции на AMD64:

      apt-get install libc6-i386
      dpkg -i –force-architecture libaio_0.3.104-1_i386.deb
      dpkg -i –force-architecture oracle-xe_10.2.0.1-1.1_i386.deb

    • за RPM-базирани дистрибуции:

      rpm -ivh oracle-xe-10.2.0.1-1.0.i386.rpm

  3. първоначално конфигуриране на сървъра:

    Конфигурирането вече е независимо от дистрибуцията. Преди да се извършването на тази операция сървърът все още не работи. След като тръгне обаче, той ще отвори два TCP порта – един порт за изключително приятната web администрация (Application Express) и още един за комуникация със самия сървър (Database Listener). Струва си обаче да се отбележи, че докато Database Listener слухти на всички IP адреси, Application Express кисне само на 127.0.0.1, което го прави малко неудобен, ако базата данни е инсталирана на отдалечен сървър. Установих, че това може да се промени едва на по-късен етап в самата web администрация, но до тогава лично аз си инсталирах малката програмка redir (пакетът в Debian е едноименен), с която пренасочих всички заявки към порт 8080 на публичния IP адрес към
    127.0.0.1. След като приключи работата, тя лесно може да бъде спряна, като по този начин се запази сигурността от недоброжелатели.

    1. изпълнява се командата:

      /etc/init.d/oracle-xe configure

    2. избира се порт за Application Express (обикновено 8080);
    3. избира се порт за Database Listener (обикновено 1521);
    4. избира се парола за системните потребители;
    5. указва се дали сървърът да тръгва при стартиране на машината;
    6. в този момент сървърът пали и е готов за работа;
    7. добре е променливите необходими на Oracle клиентите да са налични в средата. Файлът /etc/profile е много удачен за целта:

      export ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server
      export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib

    8. също така е добра идея пътят до Oracle библиотеките да бъде описан в /etc/ld.so.conf в случай, че някакъв допълнителен софтуер ще ги използва:

      echo ‘/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib’ >> /etc/ld.so.conf
      /sbin/ldconfig

  4. администрация на Oracle Database 10g Express Edition:

    Веднъж инсталиран, сървърът може да бъде администриран с всевъзможни инструменти:

    • шаренкият Application Express, който по подразбиране се намира на адрес:

      http://127.0.0.1/apex/

      Отдалеченият достъп може да бъде включен с в SQL*Plus конзолата като sysdba се изпълни:

      EXEC DBMS_XDB.SETLISTENERLOCALACCESS(FALSE);

    • стандартният конзолен инструмент SQL*Plus, който обикновено се намира в:

      /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/sqlplus

    • графичният инструмент Oracle SQL Developer;

    ЗАБЕЛЕЖКА: SID по подразбиране за така инсталираната база е XE.

От тук нататък следва щастие !.. освен ако не се наложи инсталиране клиентската част…

P.S.: Всеки може да се чувства свободен да поправи грешките, които определено съм допуснал. :)

July 7th, 2006 by Valery Dachev

Проблематизация

Определено не и от леките ми дни. Започна с уплахата, че съм загубил страшно важен за мен човек. Слава Богу, фалшива тревога. Но достатъчно реална, че да ми разклати възприятията и настроението… Не знам как ще преживея още един такъв случай просто…

Малко след събуждането си установих, че за не знам кой път тази седмица при редовното рестартиране на web сървъра на Мантра всички сайтове изчезват. Вместо добрия стар Apache, се появява някакъв глупав perl процес наречен ShellBot (написан от някой си от Atrix Team). Тъпо, че вече две седмици оставям някакво script kiddie да си играе с машинката ми и съм си за бой… Всъщност това му беше първият успешен опит от доста време насам. Мързеше ме да търся мястото, от където пробива, а и разчитах на малко security мерки, които бях взел. В общи линии, нямаше как да стигне извън сайта, който е компрометирал. Тази сутрин обаче вече ми писна на шапката и с Илиян се хванахме да видим какво става. Човечето пуска дотолкова страндартни неща, че едно търсене в Google установи проблема – изпълняваше команди през PHP благодарение на бъг в по-стари версии на phpBB (няма да слагам връзка към него, за да не се излъже някой заблуден да си дръпне това творение). От една страна са си виновни уеб-майсторите, задето инсталират и забравят, а от друга съм аз, задето не съм спрял изпълняването на команди през PHP. “disable_functions = exec,passthru,system,proc_open,shell_exec” в php.ini свърши чудесна работа. Забраняването на shell_exec() функцията автомагично спира и backtick оператора. За капак сложих и едно “safe_mode_exec_dir = /tmp“, тъй като по подразбиране при мен всички сайтове работят в safe mode, а по едно “open_basedir” ограничение ги спира да пишат извън директориите си (в частност и по “/tmp”).

Денят продължи. И то как – една от машините на econ.bg групата сдаде багажа. Всъщност още не знам дали е SCSI контролера или диска и, но все едно дискът спира в произволни моменти. Язък за хубавия надпис “Hewlett-Packard NetServer E800″. Още по-тъпото е, че, при рестартиране, fsck тръгваше с грешно подадени опции, а скриптовете си мислеха, че вади грешка. Както и да е, наложи се аварийно да търча до сървърното на Spectrum Net в Изток. Мъчих, правих, струвах.. успях да изкопирам данните на една от другите машини и реших, че тази (и без това плачеща за преинсталиране с вехтия Red Hat 7.2 Enigma на нея) забрах към къщи. Ще видим дали Debian-чето ще я огрее. До неделя смятам да е up-and-running, ако наистина няма сериозен хардуерен проблем.

Прибирам се в офиса и се опитвам да довърша подкарването на Oracle Database 10g Express Edition от тяхното Debian repository… обаче на AMD64 архитектура. И PHP поддръжка за всичко това. Мъка-мъка…

… и така до сега.

P.S. Забравих да спомена.. тъй като съм на Debian Testing, последните обновявания на Proftpd (модулите за mysql, pgsql, ldap и т.н. вече са в пакета proftpd, а не в отделни пакети) и Courier (сменен е моделът за аутентикация) допълнително ми загубиха времето…

May 4th, 2006 by Valery Dachev

Брао уе, Валери

Несъобразителността ми пак се прояви, но с моите камъни по моята глава. Преди време бях написал едно PHP скриптче, което да помогне при смяна на кодирането на базите, таблиците, колонките и данните в MySQL бози данни. Тръгвам аз да търся през PhpMyAdmin в една база на машинката ми (всъщност тази, в която съхранявам телефонни номера, адреси, emails, ICQ номера и пр. и пр.). Нищо не намирам. Всичко в базата е маркирано като CP1251 и с твърдото убеждение, че вътре все пак има UTF-8 данни, решавам да сменя със скрипта въпросното кодиране. Пускам го… сериозно се забави. За моя изненада всичко в таблицата става на маймуница. Оказва се, че данните вътре наистина са били в CP1251. За капак, без да искам, съм пуснал скрипта върху всички бази на потребителя и резултатът беше трагичен – всичките ми блогове в питанки !!! Мамка му !. Добрата новина е, че правя daily backups всяка сутрин в 6:00. Загубата беше в два коментара в блога ми и посещенията му. Здраве да е. Ще ми се да се извиня на автора на единия коментар (авторът на другия вече се псува, че е направил гафа). Отделно заминаха и всякакви снимки от галериите и коментариите по форумите на 3-4 канала, ама… боли ме (с ударение на “о”) ! И тъй като backups ги правя с копиране на директорията с базите (а те са около 3Gb общо), по никакъв начин не можах да възстановя базата с телефоните. Слава Богу, специално на нея правя и обикновени backups с mysqldump… И все пак ме е яд. Дае*а и power users… като себе си !

А иначе поводът да се разровя беше, че покрай разни блогове тук-таме изникна едно човече – много отдавнашен кадър от канала ми. Усмихнато ми е едно такова, въпреки антипатията ми към Русе (като град) напоследък. Харно е едно такова да видиш положителни промени у хората… :)

March 6th, 2006 by Valery Dachev

Spectrum

??мало едно време в Абсурдистан ??нтернет доставчик на име Spectrum. Не съм запознат с с обстоятелствата, вливането на които е довело до това, че ма??ините на група сайтове, които администрирам, са се оказали co-located там. Ясно е обаче, че притежават някои квантово-механични свойства, като например това, че никой не знае къде точно се намират, а опитите това да се установи водят обикновено до локализирането на всички други ма??ини, но не и на тези. Даже самото място “там” е не точно определено, доколкото постоянно се мени, а подходът към намирането му е вероятностен. Това ми се наложи да разбера снощи…

Започна се с един разговор (малко след прибирането ми от Казанлък), от който се установи единствено, че с една от ма??ините има проблем. Гнусен Red Hat 7.2 с пълен диск. Пълен диск с логове. Логове с PHP гре??ки. PHP гре??ки, че няма връзка до Oracle базата. Oracle база, която се намира на ма??ина с достъп само по вътре??ен интерфейс. ??нтерфейс, по който явно нищо не идва??е. Може би съм необразован или пък глупав, но не можах да намеря пакети за Red Hat 7.2 с tcpdump, iptraf, traceroute, tcptraceroute и т.н.. Как се upgrade-ва такова животно – нямам идея (имам една всъщност и това е upgrade до debian)… Рестартирания на интерфейса и въобще на ма??ината не помогнаха. Никаква връзка от ма??ината до вътре??ния интерфейс… Проблемът явно бе??е хардуерен.

Последваха разговори с поддръжката. Обясних проблема, както и елементарната топология. Не знам на колко ду??и и не знам колко пъти. Нямали в момента физически достъп до сървърното. Пратиха човек (от Люлин до ??зток). Всичко било наред. Сменил кабела на ма??ината, сменил и порта на switch-а, рестартирал го.. бла бла… Никакъв ефект. Около 23 ме взимат от къщи и тръгвам към ??зток, за да прекомпилиране на ядро, че да сменя аварийно мрежовата карта с някаква подръчна, и пристигнах, за да установя, че са пипали друга ма??ина (макар че по IP би трябвало да са я идентифицирали), че кабелът на тази е сменен с такъв с глупав конектор, който се е извадил. Разбира се, никой не е обърнал на лежащия на пода изваден кабел, нито на факта, че ма??ините са четири, а светят само три порта. Надписах ма??ините и си тръгнах…

P.S. Подочух, че ма??ините са местени по няколко пъти, тъй като в единия случай съседи се оплаквали, в другия – багер изровил кабелите, в третия кой-кого бил купил… за останалите се не знае…

January 18th, 2006 by Valery Dachev

lighttpd + fastcgi + php

Както е известно, на??ата мрежа приютява може би най-големия webchat, който може да съществува. Написани от dzver на PHP и разчитащ изключително на javascript чат обаче товари ужасно. 800 постоянно висящи процеси (за всяка връзка по един) в Apache ядат безкрайно много памет и карат всеки сървър да клекне. След всички оптимизации на Apache и на ма??ината въобще, Mantra е като че ли неспособна да понесе повече. Затова тези дни тръгнах да експериментирам на гърба на горките потребители и тази вечер ще се види доколко съм успял.

Доколкото на ма??ината работят стра??но много сайтове с всевъзможни изисквания, модулите на Apache и раз??иренията на PHP са значително повече от тези идеално оптимизираното количество необходимо за самия webchat. Опитът показва, че всеки потребител заема около 3 Мб оперативна памет. Затова целта бе??е да пусна самия webchat някак отделно. В крайния вариант на установката съм се спрял на lighttpd и PHP стартирано от неговия FastCGI модул. На сайта на lighttpd могат да се намерят много полезни публикации за настройката на FastCGI и оптимизирането на сървъра. Ето и някои специфични настройки в lighttpd.conf със съответните коментари към тях:

### включен е само един единствен модул и това е FastCGI
server.modules              = (
           "mod_fastcgi",
)

### този ред увеличава максималния брой отворени файлови дескриптори на lighttpd
### и не включва тези на CGI програмите, които работят. за всеки случай тук са
### увеличени, макар това да се препоръчва само в случаите, когато в error.log на
### lighttpd се появят гре??ки от типа на "... accept() failed: Too many open files"
server.max-fds = 1024

### "Keepalive Requests" фунционалността дава възможност в рамките на една връзка
### да се обработят няколко заявки една след друга. Тъй като в самия webchat има
### доста картинки, давам възможност 10 от тях да се заредят една след друга.
server.max-keep-alive-requests  = 10

### макс. изчакване след обработка на заявка до подаването на следващата е 2 сек.
server.max-keep-alive-idle = 2

### този ред дава възможност lighttpd да си спести извикването на stat() функцията
### за всеки файл, като ке??ира състоянието му и го следи с помощта на FAM
### (http://savannah.nongnu.org/projects/fam/)
server.stat-cache-engine = "fam"

### проследяването на символичните връзки и проверката на правата за достъп до
### всеки клон, както и зациклянето на връзките, отнема време. ако няма такива,
### както е в случая, е добре тази функционалност да е изключена.
server.follow-symlink = "disable"

fastcgi.server              = (
        ".php" => ((
### следващите два реда указват съответно минималния и максималния брой
### стартирани FastCGI процеси. за PHP всяка от тези две стойности трябва да се
### умножи по стойността на PHP_FCGI_CHILDREN променливата, която, ако не е
### установена по-долу, има стойност по подразбиране - 8.
                "min-procs"             => 1,
                "max-procs"             => 1,
### това задава граничната бройка на чакащи заявки за един процес, за да
### се стартира друг, който да започне обработката. 1 не е добра стойност
### по принцип, но, заради незавър??ващите PHP процеси, не мога да си
### позволя заявки, които да ги изчакват
                "max-load-per-proc"     => 1,
### дава броя секунди, след които неизползван процес да замре. прекаленото
### намаляване на тази стойност води до увеличаване на натоварването при
### непостоянна честота на заявките. увеличаването и пък води до прекалено
### използване на системните ресурси, така че трябва да се търси баланс
                "idle-timeout"          => 10,
                "socket"                => "/tmp/php-fastcgi.sock",
### тази настройка изключва проверката за съществуване на документа преди
### подаването му към скрипта. от една страна наличието на тази настройка е
### добре, защото не се задейства изли??но PHP процес, който да обработва
### нещо несъществуващо. от друга изключването на проверката спестява
### извикването на stat() за съответния файл. добре е да е изключен при малък
### брой обръщения към несъществуващи документи (с това раз??ирение)
                "check-local"           => "disable",
### към извикването на PHP интерпретатора е подаден допълнителен параметър
### за пътя към специфичния за сървъра php.ini файл.
                "bin-path"              => "/usr/bin/php5-cgi -c /path/to/php.ini",
                "bin-environment" => (
### следват настройки на самото PHP. първата променлива на средата определя
### броя PHP процеси, които да се пуснат. в моя случай бройката е по-голяма,
### броят висящи процеси е минимум броя на online потребителите. втората
### променлива определя броя заявки, които PHP процесът да обработи преди
### да погине. кончината му води до автомагично разчистване на използваната
### от него памет, но и до малко натоварване необходимо за стартиране на нов
### процес
                        "PHP_FCGI_CHILDREN" => "1024",
                        "PHP_FCGI_MAX_REQUESTS" => "40"
                )
        ))
)
January 17th, 2006 by Valery Dachev

ПСБО: Hall of Lame

Става въпрос за Поделение “Социално-Битово Осигуряване” към СУ. ?? даже не са те основните виновници. Става въпрос за изцепката описана тук (дано темата не е изчезнала безкрайно :)). Все пак screenshot-ът си остава.

До колкото се простират познанията ми за системата, сървърната част е код на Perl изписан от Георги Пенков (доколкото ми е известно, води курс по Perl във ФМ??). CGI приложението, за мое голямо учудване, се намира в доставчика на П”СБО” – Атлантис. Аргументи в полза на това не мога да измисля – shame. Връзката до там се осигурява от wireless. Access Point-ът се намира на 18ти блок в Студентски град, а устройството на П”СБО” – на около 400м (пак по твърдения на публикацията във форума) по горните етажи на блок 42Б. Връзката не е криптирана и се разчита на скриването на сесийния ключ – shame. Връзката на П”СБО” към Атлантис не се тунелира (нито PPPoE, нито PPTP… какво остава за някакъв тип stunnel, IPsec и други такива сложни думички) – shame. Посветена им е мрежа от публични IP адреси и жените на касите се свързват към системата по HTTP без каквато и да е криптировка, вероятно само с Basic HTTP Authentication – shame. Красотата е в това, че някой явно си е постарал, за да опровергае сляпата увереност на г-н Горанов (изп.директор на П”СБО”) и доставчика му. Системата плаче за security audit !