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 ? :)).
Valery's Mlog
Mindlog of a FreakArchive for the ‘Linux’ Category
Ще си спестя въведението за това кои са Oracle и какъв го дирят в моя блог. Така се случи, че в рамките на една седмица си имам сериозно взимане-даване с техните продукти. Един от тях е Oracle Database 10g Express Edition. Етикетът “Express Edition” стои върху група от продукти предназначени основно за развойна и учебна дейност. Пакетът включва напълно функционална база. Поради целите, които си поставя този edition, софтуерът има някои ограничения (добра статия за това има на този адрес):
- сървърът може да адресира максимум 1Гб памет;
- сървърът може да работи само върху един процесор;
- сървърът поддържа най-много една база данни (не схема !);
- сървърът се разпростира на максимум 4Гб дисково пространство;
В крайна сметка, тези ограничения не са толкова фатални за повечето случаи. Особено ако става дума за не толкова натоварени web приложения. Това са и част от причините да ми се наложи да се занимавам с нещо подобно, въпреки антипатията си към Oracle по принцип. Сега спирам да разтягам локуми и започвам страшно накратко и стъпка по стъпка – така, както си го записвах, докато инсталирах:
- изтегляне на необходимите пакети:
З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
- в /etc/apt/sources.list се добавя реда:
- за DEB-базирани дистрибуции без apt-get:
- за RPM-базирани дистрибуции:
- изтегля се oracle-xe rpm-пакета от този адрес
- за DEB-базирани дистрибуции с apt-get:
- инсталиране на сървъра:
- за 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
- за DEB-базирани дистрибуции с apt-get:
- първоначално конфигуриране на сървъра:
Конфигурирането вече е независимо от дистрибуцията. Преди да се извършването на тази операция сървърът все още не работи. След като тръгне обаче, той ще отвори два TCP порта – един порт за изключително приятната web администрация (Application Express) и още един за комуникация със самия сървър (Database Listener). Струва си обаче да се отбележи, че докато Database Listener слухти на всички IP адреси, Application Express кисне само на 127.0.0.1, което го прави малко неудобен, ако базата данни е инсталирана на отдалечен сървър. Установих, че това може да се промени едва на по-късен етап в самата web администрация, но до тогава лично аз си инсталирах малката програмка redir (пакетът в Debian е едноименен), с която пренасочих всички заявки към порт 8080 на публичния IP адрес към
127.0.0.1. След като приключи работата, тя лесно може да бъде спряна, като по този начин се запази сигурността от недоброжелатели.- изпълнява се командата:
/etc/init.d/oracle-xe configure
- избира се порт за Application Express (обикновено 8080);
- избира се порт за Database Listener (обикновено 1521);
- избира се парола за системните потребители;
- указва се дали сървърът да тръгва при стартиране на машината;
- в този момент сървърът пали и е готов за работа;
- добре е променливите необходими на 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 - също така е добра идея пътят до Oracle библиотеките да бъде описан в /etc/ld.so.conf в случай, че някакъв допълнителен софтуер ще ги използва:
echo ‘/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib’ >> /etc/ld.so.conf
/sbin/ldconfig
- изпълнява се командата:
- администрация на 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.
- шаренкият Application Express, който по подразбиране се намира на адрес:
От тук нататък следва щастие !.. освен ако не се наложи инсталиране клиентската част…
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 (сменен е моделът за аутентикация) допълнително ми загубиха времето…
Разглеждах FAQ страницата за web-майстори на Google, когато попаднах на интересна технология наречена Link Prefetching, която Google използват. Накратко, тя дава възможност браузърът да бъде инструктиран да придърпа, когато не е зает, някои адреси, които има вероятност да бъдат посетени. Google го правят това за първите няколко резултата от извършеното търсене и в това има известна логика – докато разглеждам резултатите, дръпва някои от тях, цъкам и те се зареждат мигновено. Най-популярните браузъри, които го поддържат, са Firefox и Netscape 7.01+. Това може да се провери на този адрес.
Проблемът е, че опцията е включена по подразбиране във 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” хедър, защото това е един чудесен начин за симулиране на цъкания… :-P
POP преди SMTP (или “roaming users”) е функционалност, която позволява клиентите на SMTP сървъра да изпращат поща без SMTP автентикация. Оторизацията става, като се използва автентикацията в POP и IMAP протоколите на базата на IP адреса на потребителя. ??менно това е целта на опцията в повечето пощенски клиенти “Проверка на пощата преди изпращане” или нещо от сорта. В комбинацията Qmail+Vpopmail (стига да са компилирани с подходящите опции) това става автомагично с помощта на smtp.tcp файла, който Vpopmail поддържа актуален, а Qmail чете. Тъй като това не е някакъв тип стандартна база за съхранение на roaming users, подходът при различните SMTP сървъри и комбинацията им с други POP/IMAP сървъри е различен.
Един от начините това да бъде постигнато по-универсално е пакетът 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 нещо ми лазят по нервите. Днес ще се чете…
Евалата на тоя проект. Снощи по незнайни причини реших, че е крайно време да оправя Windows-а на машината си. Нещо се бе случило с администраторската ми парола… или по-скоро аз и бях случил нещо, защото по никакъв начин не можах да се сетя каква е. Така е сигурно вече половин година, но… на кого му трябва Windows ?! :)
Решението се оказа Emergency Boot CD. Изтеглих Proфесионалната версия. Пуснах “.exe” файла с последния останал потребителски акаунт (предназначен за купони, колкото да се тегли и пуска музика), той генерира съответния “.iso”, записах го (под Linux, защото Windows потребителят нямаше чак такива привилегии), стартирах, казах, че смятам да сменя паролата на съответните акаунти, изпразних паролите им и… voila !
Всъщност всичко едва сега започваше: някои от малкото инсталирани неща гърмяха или бяха със стари версии, други пък полезни въобще ги нямаше. Имаше и 700 Мб Delta Force, който набързо се размина със съществуването си. Затрих сума неща, разчистих, инсталирах други, последва update, service pack 2 и магически всичко блесна. Остава дефрагментиране на диска. Обновяване и на драйверите… а след това – да се заколя с някое-друго Visual Studio. Уви, съдба !…
Силно съм разочарован от DotDeb. Не стига, че PHP5 пакетът им създава??е какви ли не проблеми, но последно и на testing не може да се инсталира, заради зависимостта от отдавна изчезналия пакет libmm11. ?? това откак качиха някакви пакети, за да заместят поне частично загубените при съсипването на сървърите им данни. За съжаление, от този момент насам – никакво развитие…
За да не си играя да компилирам от изходен код цялото 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 – работата на стария заблуждаващо минава без гре??ки, но такива се появяват по време на работа на кодираните скриптове.
Някаква трансперанта с надпис “Hosting” висе??е между началото и края на деня. Опитах се да намеря читаво местенце в чужбина, където безплатно да кача малко аудио и видео файлове за теглене покрай сайта на приятел-музикант. Преди около половин година намерих фирма, която предлага подобна услуга (100 Мб пространство, екстри от FTP достъп, PHP, MySQL). Никъде не пи??е??е обаче, че има ограничение в големината на тегления (не на качван) файл. Това ограничение обаче лесно се прескача с помощта на малък PHP script, който получава като параметър името на файла и връща съдържанието му. Той не подава “Content-Length” header-а. Явно обаче веднъж на половин година минава нещо, което забърсва големите файлове. Колко неприятно ! Пак ще качвам.
??зпробвах криптирането на 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 хранилища.
Debian GNU/Linux по замисъл е дистрибуция изградена от изцяло от свободен софтуер, разбирането за което е описано в Debian Free Software Guidelines (DFSG). Един от лицензите несъвместими с тези насоки е Sun Community Software License (SCSL) (по-подробно това е разяснено тук), което прави невъзможно включването на Sun Java официално в Debian. Въпреки това, може да се забележи, че много от пакетите зависят от пакети като “java2-runtime”, “j2re1.4″, “j2re1.3″ и т.н.. Всъщност “java2-runtime” е виртуален пакет, който може да бъде някаква Java виртуална ма??ина, доколкото имаме редица имплементации на такава. Това, което ме гложде??е отвътре е, че на своя Debian имам инсталирана runtime среда така, както я предоставят от Sun, но пакетната система няма??е как да знае това. Просто не можех да инсталирам пакети зависещи от наличието на такава. “Като няма кого да пита??, пита?? Google.”
Единият проект, на който попаднах е 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. :D
UPDATE: Капитански дневник. Звездна дата 1114770852.
Sun Java Development Kit 1.5.0 Update 2 + NetBeans 4.0 Bundled не може да бъде направен на пакет по този начин, тъй като самата инсталация вече е някакъв InstallShield писан също на Java и не протича по същия начин, както се очаква от другите пакети.