• сървърът може да адресира максимум 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-базирани дистрибуции:
     • изтегля се 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.: Всеки може да се чувства свободен да поправи грешките, които определено съм допуснал.

Малко след събуждането си установих, че за не знам кой път тази седмица при редовното рестартиране на 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 (сменен е моделът за аутентикация) допълнително ми загубиха времето…

Проблемът е, че опцията е включена по подразбиране във Firefox и може да изиграе много лоша шега на не малкото люде на трафик, а и на тези, които делят връзката си други хора (напр. в претрупан офис). Въпросът много кратко е дискутиран в страницата посветена на тази възможност и, лично на мен, аргументацията за включването и по подразбиране ми звучи меко казано нелепо. Доколкото тази функционалност активно се използва от Google, предварителното зареждане може да се извърши на всевъзможни сайтове. За такива потребители е препоръчително да изключат възможността. За съжаление най-лесният начин да стане това на този етап е да посетят адрес “about:config“, да намерят натройката network.prefetch-next и с двойно цъкане да променят стойността (последната колонка) от “true” на “false”. Друг вариант е инсталацията на едно от най-популярните разширение за Firefox напоследък – Fasterfox, в което тази настройка (и редица други) е изнесена (Tools -> Extensions -> Fasterfox -> Options -> Fasterfox -> Enable Enhances Prefetching).

UPDATE: Любопитно ми е, колко от pay-per-click системите проверяват за “X-moz: prefetch” хедър, защото това е един чудесен начин за симулиране на цъкания…

Един от начините това да бъде постигнато по-универсално е пакетът pop-before-smtp. Като всяко нещо, това си има и предимства и недостатъци. Предимството е, че не изисква кръпки за различните сървъри, защото в тях е вкарана поддръжката за повечето от тях. Недостатъкът е много злобен – въпросният инструмент анализира пощенските логове, т.е. разчита на това, че такива има и са в точно определен формат (макар че това може да се пипне в конфигурационния файл). Пакетът е достъпен за потребителите на Debian под същото име. Зависи от Perl и няколко негови библиотеки. Макар и непълно, кратко описание на инсталирането и конфигурирането може да се намери на този адрес.

По принцип конфигурирането е в четири аспекта и в общия случай се свежда до разкоментиране на подходящите редове:

• настройки на самото pop-before-smtp. Тук влиза нивото и мястото за debugging информация в случай на проблеми.
• настройки за POP/IMAP сървъра. Трябва да се пипне мястото на логовете в променливата $file_tail{‘name’} и формата на логовете в променливата $pat, като има предефинирани такива за по-популярните сървъри. Струва си отново да се отбележи, че имената на демоните може да с различават между дистрибуциите, както и формата на датите, ако е зададен системен локал.
• настройки за SMTP сървъра. Отново конфигурирането започва с разкоментиране на подходящия за съответния SMTP сървър блок. С Postfix нещата са доволно безпроблемни. Само да отбележа, че за ползване BerkeleyDB база, на системата трябва да е инсталиран допълнително libberkeleydb-perl пакета. При Qmail положението малко по-забавно, доколкото той винаги е бил адски несъвместим с всичко, а авторите му – твърде превзети, за да направят нещо по въпроса. О??е повече, че в гореспоменатото ръководство Qmail въобще не се споменава. Та… отново се разкоментира съответния блок. Това, което трябва да се поправи в него е пътят до tcprules (в Debian – /usr/bin/tcprules) в $TCPRULES и да се устновят локалните мрежи в mynet_tcprules. Може да се наложи и в началото на sync_tcprules да се добави umask(022), в случай, че SMTP сървъра не може да изчете файла. Следва връщане чак до горе, за да се смени пътя до файла с генерираната база в променливата $dbfile (в Debian – /etc/tcp.smtp.cdb)
• настройка на самия SMTP сървър. За Postfix отново описание има. Само от пътя сочен от $dbfile трябва да се махне раз??ирението “.db”, което Postfix явно добавя автомагично. Учудващо в Qmail не се пипа нищо ! Може евентуално да се наложи преименуване на /etc/tcp.smtp файла, за да не може всякакви автоматични инструменти на негова основа да презапи??ат /etc/tcp.smtp.cdb.

Сега остава заклинанията изказани по-горе да се окажат подходящи за наумената магия.

Azureus. Наложи ми се тези дни да търся нещо в родните BitTorrent мрежи. Даже не помня какво. По принцип бягам от всякакви peer-to-peer хави. Някаква антипатия ме гони. Както и да е… това, което си намерих за Linux (а се оказа и за Windows) е Azureus. Написано на Java, свободно… чудесно просто. Снощи се присъединих към пиратското множество, като си изтеглих всички епизоди на “На всеки километър” (чието завръщане на екрана по някаква причина оплюват).

Proxifier. Нямам Интернет тия дни вкъщи по различни причини. Само достъп до HTTP прокси, върху което имам административен контрол. Отпуших му CONNECT заявките за всички портове. Остана само да прекарам нещата от там. Цъкам си по Windoze-а тия дни и нямам инсталирано локално прокси, през което да прекарам всички приложения (както съм направил под Linux), за да може само на едно да правя промяната. Тръгнах да карам приложение по приложение. Някои обаче не поддържат използване на HTTP прокси. След известно ръчкане из Интернет попаднах на Proxifier – прихваща всички изходящи връзки и ги прекарва от дадените прокси сървър(и) (SOCKS4/5, HTTP или HTTPS). Култ !

Дефрагментиране ? Абсолютно безуспешни опити – дефрагментацията запецва и до там. Ръчка нещо по диска, но никакъв ефект. Продължава да кърти даже известно време след спиране на самия дефрагментатор. Майната му. Записах към 20 диска и още ще има – освобождавам място и накрая ще изпразня диска – така ще го дефрагментирам.

.NET Framework. Вчера сериозно захапах Visual Studio-то. Разучавам C#, класовете в .NEТ framework, особено що се отнася до работата с бози от данни. Тръгнах даже персистентния клас, който ползвам в PHP приложенията си, да пренаписвам на C#, но DataGrids малко го обезсмислят. И все пак си е добро упражнение. Microsoft SharePoint Services 2003 нещо ми лазят по нервите. Днес ще се чете…

Решението се оказа Emergency Boot CD. Изтеглих Proфесионалната версия. Пуснах “.exe” файла с последния останал потребителски акаунт (предназначен за купони, колкото да се тегли и пуска музика), той генерира съответния “.iso”, записах го (под Linux, защото Windows потребителят нямаше чак такива привилегии), стартирах, казах, че смятам да сменя паролата на съответните акаунти, изпразних паролите им и… voila !

Всъщност всичко едва сега започваше: някои от малкото инсталирани неща гърмяха или бяха със стари версии, други пък полезни въобще ги нямаше. Имаше и 700 Мб Delta Force, който набързо се размина със съществуването си. Затрих сума неща, разчистих, инсталирах други, последва update, service pack 2 и магически всичко блесна. Остава дефрагментиране на диска. Обновяване и на драйверите… а след това – да се заколя с някое-друго Visual Studio. Уви, съдба !…

За да не си играя да компилирам от изходен код цялото PHP5 (и покрай това да инсталирам изли??но една камара development пакети), се обърнах към добрия стар apt-get. ??зточникът, който намерих там (макар и да не съдържа eAccelerator пакети) e:

deb http://people.debian.org/~dexter php5 sid php5-5.0.4-0.4

Радостен е факта, че, за разлика от DotDeb, тук са се съобразили с факта, че на една ма??ина може да има едновременно инсталирани PHP4 и PHP5, като двете не си пречат взаимно. Благодарение на това, човек спокойно може да си компилира и инсталира раз??ирения и за двете версии. Успе??но минаха експериментите, както върху дома??ната ми ма??ина, така и върху хостинга. Проблеми направиха само няколко чужди скрипта, който използват за индекси на масиви нововъведени запазени думи като “protected”, но това лесно се проверява с нещо от рода на:

find . -name '*.php' -exec php5 -l {} \;

Такъв е и случаят с eAccelerator, който се нуждае от преинсталиране. Това е естествено, предвид големите промени и нововъведения в PHP5 и в частност в Zend Engine. По същите причини се налага и повторно кодиране на PHP скриптовете, ако това е било направено – кодирането за PHP4 не е съвместимо с това PHP5. Промени има и по encrypt.php – работата на стария заблуждаващо минава без гре??ки, но такива се появяват по време на работа на кодираните скриптове.

??зпробвах криптирането на PHP кода с помощта на encrypt.php, който върви с eAccelerator. Получи се. Оказва се обаче, че самото криптиране е различно за PHP4 и PHP5. Когато криптирах при себе си, на сървъра резултатът бе??е: “Fatal error: eAccelerator Loader can’t load code. Incorrect Zend Engine version“. Явно проблемът е в разликата между Zend Engine 1 и Zend Engine 2. Живи и здрави !

Titan Internet пък издъниха работата с AVC Broadband. Сайтът бе??е долу цяла сутрин, а след появата му се оказва със стара версия. Не ми е за това, че явно няма RAID и се оказвам със стар backup, ами това, че не са съобщили нищо на клиентите си. Глупава история.

Междувременно се изнамери и някой-друг нов кандидат за свързване в на??ата IRC мрежа. ?? те да са живи и здрави, посмях се !

То се е видяло, че не съм единствен с проблемите. То никой не е застрахован. А има и фирми къде-къде по-зле. ?? аз да съм жив и здрав и аз с моя си хостинг и да не критикувам много, че… не съм цвете за мирисане !

P.S. Ще??е ми се да споделя сайтовете за Администрация на Debian и за неофициални APT хранилища.

Единият проект, на който попаднах е Blackdown. Доколко това, което правят (а именно да портват Java) е легално, не знам. Фактът е, че от техните огледални сървъри могат да се дръпнат JRE и JDK пакети. Не е кой знае колко голяма философия. Просто в /etc/apt/sources.list се добавя реда:

deb ftp://ftp.tux.org/java/debian/ testing non-free

(ако се ползва “testing”.. но същото съществува и за “stable” и “unstable”). Следва командата “apt-get update“. От тук насетне са достъпни пакети като “j2re1.4″, “j2dk1.4″ и т.н. (откриват се лесно с “apt-cache search java“). Проблемът, който имах е, че още не са направили пакети с новата Java 1.5 (наричана Java 5), а ??аринийката определено ми хареса.

Тук от Debian отново са измислили ре??ение и то се съдържа в инсталирането на пакета “java-package”. От тук нататък, за да си направи човек собствен Debian пакет с Java Runtime Environment (JRE) или Java Development Kit (JDK), просто трябва да изтегли съответния “.bin” файл за Linux и да изпълни като потребител команда от рода на:

fakeroot make-jpkg ./jre-1_5_0_02-linux-i586.bin

(или там “.bin” файла, който е изтеглен). Ако отговори правилно на всички въпроси и не е издънил нещо (като например файлът да не в текущата директория), печалив??ият получава (пак там) напълно функциониращ “.deb” пакет. Цялата процедура е описана тук. Красотата е, че този пакет създава и подходящите символични връзки по директориите на различните браузъри, така че да сработят и Java plug-in-ите им (които също вървят даже с JRE).

От тук насетне пръстите започват да подскачат по клавиатурата в ритъма на “танца на радостта” и да къртят код в Eclipse.

UPDATE: Капитански дневник. Звездна дата 1114770852.
Sun Java Development Kit 1.5.0 Update 2 + NetBeans 4.0 Bundled не може да бъде направен на пакет по този начин, тъй като самата инсталация вече е някакъв InstallShield писан също на Java и не протича по същия начин, както се очаква от другите пакети.

Както и да е… поставих си задачата да отделя друга ма??ина за router, PPTP server и accounting. ??нсталирах я набързо Debian-Installer RC2 (не бях обърнал внимание, че само преди броени дни е излязъл и RC3). Останалото време прекарах в мигриране и стягане на набързо написаната преди вече половин година система. Ако се хвана по-сериозно, може и да я пусна свободно…

Ноооо… и това не ми бе??е мисълта. ??нтересното се получи, когато трябва??е да подкарам електронна поща на така поосвободилото се amd64. Привикнал към комбинацията на qmali и vpopmail, която относително лесно се подкарва под Debian, но пакетите просто ги няма??е в така или иначе неофициалния amd64. Не съм превърженик на “make && make install” и ре??их, че ще подходя друго яче: отдавна бях ре??ил да поразгледам Postfix и наистина се оказа нещо особено ценно, още повече, че всичко замина директно в MySQL. Възмущавах се, че така и не направиха едно читаво описание на това кое какво е и да дадат примерни структури за тези бази и съответните файлове, но съм се лъгал: на сайта на Postfix Admin намерих едно кратко (макар и не изцяло разяснено) ръководство за инсталиране на Postfix, което ми помогна много бързо да подкарам работещо ре??ение включващо Postfix (с виртуални домейни и MySQL поддръжка), Courier POP3(-SSL)+IMAP(-SSL) и Squirrelmail. Тези дни се надявам да намеря място за SpamAssassin и ClamAV в цялата картинка, за да бъде по-пълна, а ако намеря и повече свободно време да задълбая повече в тези неща, ще скалъпя нещо на български по въпроса.

??ска??е ми се да направя и някакъв елегантен изход от обстоятелството, че пощенският сървър “corwin” всъщност се намира в рамките на една локална мрежа и не разполага със собствен публичен адрес (неуредици в Digsys ?), а стои зад ма??ината “gateway”. Под думата “елегантен” си представях нещо от типа: на “gateway” да има инсталиран SMTP сървър, като MX записите за Internet да сочат неговия публичен IP адрес, а за локалната мрежа – частния IP адрес на “corwin”. Така всяка поща, която идва от ??нтернет, ще??е да отива на на “gateway”, който да ползва “corwin” за Smart Host. Тя пък от своя страна директно ще??е да обработва локалната поща и да играе ролята на SMTP сървър за клиентите ни. Спънката се оказа, че “RFC-1918 addresses are never valid for MX targets on the public Internet!”. Единият вариант бе??е да се опитам да изключа тази проверка от smail, но пък не бе??е ясно дали, ако мина на друг SMTP сървър, щях да мога да го направя. Другият вариант, който всъщност реализирах, бе??е въобще да махна какъвто и да било SMTP сървър от “gateway” и да правя DNAT за връзките откъм Internet към 25ти порт до “corwin”. Най-красивото е, че работи перфектно и не изисква никакви други промени…