a direct publicism site
personal pages of Yasen Pramatarov

dom.bg

Ново място, с нови дрешки


От днес страниците ми са преместени на yasen.lindeas.com - моля който има препратки към стария ми адрес да ги обнови.
Засега тук съдържанието е малко, всъщност единственото нещо засега е тази публикация, но смятам в близките дни да пренеса цялото съдържание от стария ми адрес тук. Всички записи в бележника, заедно с коментарите ви, както и тези във фотодневника и уики-то ще бъдат пренесени тук. Ще запазя цялата информация и при пренасянето ще проверя препратките и адресите в статии и коментари - ако има невалидни препратки, ще ги поправя, за да сочат към правилните места.
Ще се погрижа старите адреси да се достъпват и тук.

Причините да се преселя тук са много и различни. Ще разкажа за тях скоро. Освен сменен адрес, имам и нов софтуер на сайта - аз отдавна се занимавам с Drupal за изработка на сайтове на други хора и най-накрая реших да се възползвам и аз. Този нов стар мой сайт се задвижва именно от Drupal. Има много неща за дооправяне, най-вече козметики по изгледа, но тях ще ги оправял в движение.
Новата система на сайта ще ми даде повече свобода в работата ми по фотодневника. Макар да доказах, че фотодневник (а и цял личен сайт всъщност:) е възможно да се поддържа с Blosxom, в стария ми сайт започнаха да ми липсват много и различни малки неща, които за обикновен блог не са необходими, но за по-преценената и художествена визия на фотодневник са си нужни.
Уики-то също ще бъде интегрирано тук, като цялото съдържание ще преместя и ще улесня редактирането му - нещо, което спираше много хора от участие в проектите там, защото старото уики, да бъда честен, си беше трудно за работа.

И така - малко преди блогът ми да навърши три годинки се реших най-накрая на голяма промяна. Нов софтуер, с повече възможности и нова структура на сайта, която ще събира всичко под името yasen.lindeas.com.



Tags:
11 Октомври, 2006 - 10:02

 
 

Mediawiki на dom.bg


Наскоро писах как можете лесно и бързо да инсталирате и пуснете в употреба уеблог-системата WordPress на хостинг-място, осигурено от доставчика dom.bg. Причината да смятам това изобщо за полезно по някакъв начин е, че въпросният хостинг е много евтин. Има по-добри, не казвам, че е добър. Макар на всички мои писма да е било отговаряно винаги в рамките на най-много няколко часа, дори и привечер и нощем. Но все пак този хостинг има едно отличително качество и то е ниската цена. Не, изобщо не рекламирам този доставчик! Достатъчно съм се измъчил с услугата му, за да пожелавам такива кахъри на хората… Причината да пиша тези малки “спасяващи” решения е, че сигурно има и други хора, които като мен вече са се подлъгали и са си купили хостинг именно от dom.bg. Надявам се тези неща да помогнат на някого, който е при такъв или подобен доставчик, да осъщетвява идеите си в мрежата поне малко по-лесно и удобно.

——

Ако сте опитвали да инсталирате MediaWiki на акаунт в dom.bg, сте забелязали, че се появява същият проблем, както при WordPress - след инсталация страницата не се зарежда, връща се грешка 500. Причината отново е във факта, че PHP се изпълнява не като модул, а през CGI. Работил съм с повечето от свободните проекти за малки уеб-сървъри и много често ми се е налагало да пускам PHP през CGI. Но винаги, когато натоварването е било по-голямо, тоест въпросното php не е било “за кратко”, “инцидентно” или “единствено”, съм сменял малкия сървър с Apache. Именно защото за Apache има модули за такива неща. Използват повторно заделената си памет и т.н. Не мога да си представя как работи уеб-сървър в условия на голямо натоварване (защото каквото и да си говорим, dom.bg е един от масовите доставчици, доста страници търкаля това CGI…) с PHP, извикван всеки път през CGI, за всяка php-страница.

Но все едно, ето как да си пуснете MediaWiki на dom.bg:

Отваряте файла /includes/OutputPage.php и закоментирате реда

header(“HTTP/1.1 {$this->mRedirectCode} Moved Permanently”);

При мен беше под номер 427. Под него добявате следния ред:

header(“Status: {$this->mRedirectCode} Moved Permanently”);

Закоментирате и реда

header(“HTTP/1.1 304 Not Modified” );

При мен беше под номер 122. Под него добавяте следния ред:

header(“Status: 304 Not Modified” );

И след това MediaWiki вече е готово за “пълнене” със съдържание. Само първата промяна ще е достатъчна, за да “тръгне” сайтът. Но променете и втория указан ред, за да избегнете всички възможни връщания на грешка 500 по такава “cgi”-причина.

Отново, както ии при WordPress, може да се постави кратка проверка на местата, където се изпращат http-заглавките и да се изпраща адекватен отговор, в зависимост от това дали PHP е като модул или е през CGI. Ако има интерес, ще публикувам такава проверка и може да пиша на разработчиците да я добавят. За улеснение на обновленията на версиите за такива cgi-потребители. Но мисля че засега с такъв малък хак всички ще се справят. А и dom.bg може да обновят някой ден сървърите си. Не само че са през CGI, ами и версиите на софтуера им са едни… стари, де… Ама няма значение, тяхна си работа… ;)

Смятам да не пиша повече за този проблем. Принципът ви е ясен и сигурно има страшно много други програми, които ще връщат грешки в такава среда. Ясно е какво трябва да се промени. Ако имам друг хак за “справяне” с dom.bg, принципно различен, тогава ще пиша.



Tags:
13 Март, 2006 - 19:33

 
 

Wordpress на dom.bg


Преди време Владо Герджиков имаше проблеми с доставчика на хостинг “dom.bg”. Понеже и аз съм също там (все още; засега май реших голяма част от проблемите и не ми е чак съвсем некомфортно, та може да остана до края на платения период…), реших да споделя един малък хак за хората с Wordpress.

На dom.bg PHP работи не като модул на уеб-сървъра, а като скрипт през CGI. Причините няма да коментирам - те си знаят защо са решили така. Не зная колега, който ще сложи PHP през CGI на такъв голям сървър, но все едно - това е положението.

Та един от основните проблеми при работата с dom.bg е именно този. Повечето готови системи, писани на PHP, най-често изобщо не правят проверка дали се работи през CGI. Обяснявам си го с предположението, че почти никой не би се сетил, че има публичен хостинг, който да пуска PHP през CGI. Нещо по-“екзотично” като Ruby например може и да се пусне, но пък PHP… Макар да си има модул и за Ruby. :)

При инсталиране на Wordpress на въпросния хостинг всичко минава правилно до момента, в който трябва да заредите сайта си. Тогава се връща грешка 500 (internal server error). Иначе администраторският интерфейс си работи, всички настройки и редактирания - също. Проблемът се появява при зареждане на основния сайт. Логовете на dom.bg не са видими от потребителя, можете да ги изискате с писмо до поддръжката, но в този случай не си правете труда. Ето решението…

Ако инсталирате Wordpress на акаунт към dom.bg (или изобщо някъде, където PHP работи през CGI, отворете файла /wp-includes/functions.php и намерете мястото със следните два реда:

@header(“HTTP/1.1 $header $text”);

@header(“Status: $header $text”);

Във версията, която днес инсталирах (2.0.2 - последната към момента) тези редове са с номера 2170 и 2171. Но с търсене ще ги намерите - единствени във файла са.

Това, което ще реши проблема ви, е закоментирането на първия от тези редове. Сложете коментар (“//”) пред реда, който изпраща HTTP/1.1 заглавка. Първият ред е за PHP като модул, а вторият - за PHP, изпълняван през CGI.

Не зная защо в самия код на Wordpress не са добавили точно на това място една кратка проверка как се изпълнява PHP и след това просто да се изпраща съответния ред. Може би това е възможно решение на бъг в Wordpress, но рядко бъркам и надничам в кода на WP, за да кажа със сигурност дали е бъг и дали трябва да се добави провеерка. Или може да минем само с тоози малък хак за такива “странни” хостинги като родния dom.bg. Ако някой има представа и му се занимава да чете по-подробно кода на WP, нека каже. Ако проверката е удачна, може да пратим на разработчиците поправката. Става дума за ред-два “if-then-else” проверка ;)

Приятно блогване ;)



Tags:
11 Март, 2006 - 13:05

 
 

Искате услуга?... Искайте...


Да кажа нещо за хостинг-ите у нас - за нищо не стават. И преди да продължа, да ви кажа кое е истинското решение. Вземете си машина на старо, съберете се с десетина приятеля и си дайте машината за co-location при голям доставчик. Ще ви излезе същите пари, но за сметка на това ще имате истински сървър, на който можете да правите това, което искате. Не това, което благоволи да ви даде “хостинг-ът”.
Ако ви излезе по-скъпо, вземете си dedicated server. Това е виртуална машина при голям доставчик. Няма да имате съвсем пълен контрол, но пак ще можете да правите всичко, което поискате. От което имате нужда за един нормален и хубав сайт. За много такива сайтове.
А не за малка страничка za_men.html - за това ще ви свърши работа и безплатен хостинг ;) Аз (и, вярвам, и другите от “Проектория”) засега се “хоствам”, просто защото в момента нямам възможност и време за описаното по-горе.
——
Понякога писва да си краставичар и все краставици да ти пробутват. Преди години баща ми, който и повече от мен си е градско чадо, се опитваше да обяснява на баба и дядо на село, че е много по-добре да гледат само едно нещо и да го продават. Например да отглеждат само домати - много и хубави домати. След това да ги продават и с паричките да си купуват от хоремага и чушки, и свинско, и боб, и каквото им душа сака. Ама не - в полупланинските райони е така; там и без това нищо не вирее като хората, не е като в плодородните низини, където к’вот боднеш в земята, все пораства. И хората гледаха и кокошки, и прасе, магаре, чушки, домати, фасул, картофи… Не се сещам всичко, но беше нещо като малка райска градина всеки двор. Прекрасни времена, с прекрасни хора. Но тази статия е за друго - за лошото отношение на доставчиците на хостинг, които опитват да “гледат всичко” и накрая всъщност има само за тях.
——
Каква е моята логика - ако си доставчик, доставяй това, което доставяш и го доставяй качествено. Печели пари и с парите си купувай за себе си каквото не доставяш. Не може да доставяш “уж всичко” и да тръбиш няколко години, че си хостинг-ът с най-много клиенти, а всъщност да се занимаваш наистина с много неща, но на посредствено ниво. Да, задоволяваш нуждите на средния ламер, но като се вземе предвид, че ламерите и те са хора, и те надобряват… Не ми се мисли направо.
Конкретно. Доставчикът на хостинг ми е dom.bg. Да, знам, че са “майка плаче”, но бяха най-евтините и се водех по цената. И преди някой да каже (не дай си боже някой от dom.bg, не искам да ги чувам…) “ама то за такава цена - толкова”, нека уточним нещо. Щом някой продава домати, тези домати трябва да стават за ядене. Дори и с малки букви да пише в малко листче до всеки домат “този домат става за гледане, за радване и за мятане”. Независимо от всичко всяко нещо си има нормални свои си граници. Границите на пазара са от най-старите и най-добре установени - хората разменят неща по пазарищата от време оно. С две думи - продаваш ли домат, той трябва да става за ядене. Може да не е най-вкусният, може да е най-евтиният, но доматите са за ядене. Основно за ядене.
——
Така-а-а… Платил съм си за хостинг. Знам, че не мога да очаквам чудеса, но в описанието на плана пише винаги най-общо какви са параметрите. Техническите параметри, тези неща, които ще ми подсигуряват нормалното ползване на услугата. А самата услуга каква е, къде я пише? Освен какъв обем място и трафик ми дават, кое друго е описание на услугата?
Още по-конкретно. Никой не пише дали човек получава достъп до лог-овете си. Неговите си логове, да - защото не ми пука кой ми е доставчикът, данните в логовете са си мои и аз трябва да реша дали да ги дам на доставчика. Не говоря за данните, които той събира за мен - да събира каквото си ще и каквото може. Става дума за това, което касае пряко моя сайт - това е моя информация и задължително трябва да имам копие от нея.
Не “ако поискате, ще ви копираме извадка от логовете ви”. “Извадка”? А аз може ли да ви дам извадка от цената? При поискване само?


Първото е дали има начин да имам достъп до логовете на моя хост? По-специално логовете на уеб-сървъра. Стига ми достъп само за четене и достъп само до моите логове. Може и symlink - проблемът е, че когато има грешка, нямам начин да разбера каква е точно и трябва да налучквам. Също така освен error-лога, access-логът също ще е полезен - за по-подробен анализ на посещенията.
[…]
Можем да копираме по заявка лог файловете в главната Ви папка.

Това се преживява - справям се и без логове засега, докато се оглеждам за ново място за мен и евентуално и за цялата “Проектория”. Но ми се наложи да пиша и по друг въпрос на доставчика. Не се изненадах, когато ми отговори почти веднага - тоя човек много малко спи и много се грижи за фирмата си. Да, всеки път е един и същи човек. Беше казал на Владо Герджиков, че прави този бизнес за удоволствие. Хубаво, само че май е само за него удоволствието.
Големият ми проблем напоследък е коментарният спам. И понеже опитвах различни неща - добавях забранени домейни на препращане с mod_rewrite, добавях javascript-ове, които да приемат коментари само от заредени вече форми и т.н., но с малък ефект, реших да опитам с mod_security - всички казват, че това е решението за момента. Като се замисля, наистина става и с mod_rewrite, но трябва да променям периодично генерираните в мрежата файлове със спамерски домейни, за да работят с rewrite, а не искам. Искам да ползвам готови, доставяни правила, като тези например…


Интересува ме дали има инсталиран и включен на уеб-сървъра модул mod_security
http://www.modsecurity.org/
http://www.gotroot.com/mod_security+rules
Имам нужда от този модул, заради възможността да огранича коментарния спам, който залива един от сайтовете ми. Опитах, но неуспешно да огранича спам-а с правила на mod_rewrite.
[…]
Този модул не е инсталиран. Няма нужда и от mod_rewrite (въпреки, че е инсталиран). Лесно с .htaccess може да ограничавате достъпа до определени IP адреси, а ако става въпрос за достъп от различни IP адреси, но с подобна информация, може да промените кода на скриптовете си.

Все едно съм питал за съвет какво мога да направя. Нормалният отговор би бил “съжаляваме, но този модул не предлагаме”. Точка. И “съжаляваме” да си личи, че е искрено. Защото аз съм клиентът и имам право.
А за коментара, че нямало нужда “и от” mod_rewrite направо не ми се говори. То няма нужда изобщо от такъв хостинг… ама айде… кой ме пита мен. ;) Пак казвам - може да е евтин хостингът, но нито логовете, нито mod_security е нещо, което би затруднило или би застрашило услугата на доставчика. И двете искания са неща, с които един админ се справя “между другото”. Особено това с логовете е нещо, за което аз като админ бих се сетил още при проектирането на услугата.

П.П.: И така засега моят сайт остава без по-строг и по-истински контрол на спам-а и без анализ на трафика. За мен първото е важно, а второто е бял кахър. Но за “Проектория” ще е добре да имаме анализ на трафика, тоест *логове*. Отбелязвам си в мисленото тефтерче да проуча възможностите и да обсъдим с екипа това.

П.П.П.: Не искам тук да се прави реклама/антиреклама. Но все пак препоръчайте хостинг, ако имате прекрасни впечатления! Може да обсъдим възможността за временно решение, преди някой ден да идем на вариант А, на описания в началото co-location или dedicated сървър.



Tags:
24 Януари, 2006 - 09:25

 
 
Different Photography
Make Money Fast - Work At Home
helio ocean
Cheap Macs, PCs, LCD TVs etc
Flash Drive Recovery
Ако сайтът ви е харесал, можете да ме почерпите с
или
през ePay
perdolitical manager good job trachilic
money cash casinos