ET Legacy и macOS Sierra проблем

Човек и добре да живее минава на по-нова версия на операционната система. Част от проблемите от новата версия е, че ETLegacy спря да работи поради липсата на файлове. Всъщност аз ги виждам през файловата система, но приложението не.

FS_InitFilesystem: Original game data files not found.
Please copy pak0.pk3, pak1.pk3 and pak2.pk3 from the ‘etmain’ path of your Wolfenstein: Enemy Territory installation to:
„/private/var/folders/ph/72hb8_ds1cg98mvs4xb61c9w0000gn/T/AppTranslocation/55316FBE-BCC2-43C9-B1DC-817D7B012C32/d/etmain“

Разбира се при вас цифрите може да са малко по-различни. Може да отказва да зареди и заради липсата на файла librenderer_opengl1_mac въпреки, че го има. Проблема се оказва новата защита на приложения във macOS (Gatekeeper path randomization) и решението е сравнително лесно. Трябва само да отворите терминал и да изпишете следните команди:

cd /Applications/
xattr -dr com.apple.quarantine ET\ Legacy/

след което можете да си пуснете играта.

Global Firefox Console

Firefox е един от най-любимите ми браузъри по много причини. Днес установих, че е възможно да се активира глобална конзола където той да започне да показва информация относно целия мрежов трафик от всичките плъгини, него самия и сайтовете. Единственното което трябва да се направи е да се стартира със параметър от командния ред -jsconsole. Как става това?
Windows 32 битов

"C:\Program Files\Mozilla Firefox\firefox.exe" -jsconsole

Windows 64 битов

"C:\Program Files (x86)\Mozilla Firefox\firefox.exe" -jsconsole

OSX

/Applications/Firefox.app/Contents/MacOS/firefox-bin -jsconsole

Linux

firefox -jsconsole

Това е всичко. Разбира се подгответе се за потоп от информация във глобалната конзола. На мен лично ми трябва да открия проблем при обновлението му. На версия 48.0 съм и ми казва че няма обновление. Което е лъжа при положение че има 48.0.2 налична.

HTTP debugger

Понякога човек се нуждае от услуги който надежно да използва докато праща заявки нагоре-надолу към други услуги. Разбира се… не винаги може да се дебъгне точно какво и как се изпраща нагоре, особенно когато заявките са криптирани.

И тук на помощ идва HTTPBIN. Със негова помощ може доста по-лесно да се диагностицират заявките и да се преработят.

Enabling HTTP/2 on nginx over Amazon AMI

Една от любимите oперационни системи на Amazon EC2 е тяхната Amazon AMI. Разбира се няма нищо по-хубаво когато производителя на хардуера ти доставя оптимизиран софтуер за него. УВИ има няколко проблема като най-големия е, че отделни модули са доста стари. Това е защото AMI използва някакъв миш-маш от няколко операционни системи – RHEL6, RHEL7 и дори Fedora. Във моя случай nginx е версия 1.8, но за да активирам HTTP/2 се нуждая поне от версия 1.9.5 (докато актуалната е 1.10.1). Разбира се ако изчакам още някой месец може и да ме огрее… но чакам вече година и ми писна. Затова взех нещата във свои ръце и си прекомпилирах своя версия на nginx.

1. Инсталирайте nginx – ще ви спести поне писане на конфигурационни файлове. Конфигурирайте си го по свой вкус.
2. sudo yum install pcre-devel openssl-devel #библиотечки… ще ви потрябват
3. wget https://www.openssl.org/source/openssl-1.0.2j.tar.gz
4. tar zxvf openssl-1.0.2j.tar.gz -c /lib/opt
5. wget http://nginx.org/download/nginx-1.10.1.tar.gz
6. tar zxvf nginx-1.10.1.tar.gz
7. cd nginx-1.10.1
8. ./configure –prefix=/usr/share/nginx –sbin-path=/usr/sbin/nginx –conf-path=/etc/nginx/nginx.conf –error-log-path=/var/log/nginx/error.log –http-log-path=/var/log/nginx/access.log –http-client-body-temp-path=/var/lib/nginx/tmp/client_body –http-proxy-temp-path=/var/lib/nginx/tmp/proxy –http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi –http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi –http-scgi-temp-path=/var/lib/nginx/tmp/scgi –pid-path=/var/run/nginx.pid –lock-path=/var/lock/subsys/nginx –user=nginx –group=nginx –with-file-aio –with-ipv6 –with-http_ssl_module –with-http_realip_module –with-http_addition_module –with-http_sub_module –with-http_dav_module –with-http_flv_module –with-http_mp4_module –with-http_gunzip_module –with-http_gzip_static_module –with-http_random_index_module –with-http_secure_link_module –with-http_degradation_module –with-http_stub_status_module –with-mail –with-mail_ssl_module –with-http_v2_module –with-openssl=/opt/lib/openssl-1.0.2j –with-pcre –with-pcre-jit –with-debug –with-cc-opt=’-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector –param=ssp-buffer-size=4 -m64 -mtune=generic’ –with-ld-opt=’ -Wl,-E’
9. make
10. /etc/init.d/nginx stop
11. sudo cp objs/nginx /usr/sbin
12. /etc/init.d/nginx start

ВАЖНО! Ако обновление ви презапише по-стара версия на nginx ще се наложи да изпълните точка 9 поне още веднъж. Защото това е един дърт пач върху оригиналния nginx.

Сега вече ако напишете nginx -V ще видите нейде:
nginx version: nginx/1.10.1

Оттук насетне е лесно. Отивате във конфигурационния файл и издирвате това:
listen 443 ssl;
за да го замените със:
listen 443 ssl http2;

Честито! Вече имате работещ nginx със http/2.

Забележка!!! Оригиналния nginx във AMI е компилиран със малко повечко опции. Липсващите са:
–with-http_xslt_module
–with-http_image_filter_module
–with-http_geoip_module
–with-http_perl_module
–with-google_perftools_module
но аз така или иначе не ги използвам тях.

Google Business Page линк за писане на ревю

Онлайн ревюта е един от начините за подпомагане на потребителите при процеса на избор на услуга или доставчик. Все пак никой не иска да работи със такива имащи една или две звезди придружени със съсипващо текстово ревю. А между другото е и инструмент за сладко отмъщение, всички знаем много примери как фирмите изведнъж стават отзивчиви при негативни ревюта из интернета.

Как обаче да се подпомогне писането на ревюта към Google Business Page? Реално след масивните обновления на интерфейса вече това е невъзможно със директен линк и потребителите са затруднени. Сега ще ви покажа как това може да се случи лесно и просто със помоща на Google Maps. За пример ще използваме магазина на нашите приятели от Aloha.bg.

За да изкараме пряк линк ние се нуждаем от 3 неща:
1. Име на страницата/бизнеса
2. ludoCID – цифри
3. LRD – цифри

Проблема обаче е вземането на ludoCID и LRD. Сега ще ви покажа как можете бързо, лесно и просто да ги вземете:
1. Отваряте Google Maps на настолен компютър
2. Намирате името на страницата/бизнеса. Във нашия случай е Aloha Bulgaria. И търсите за него.
3. Отивате където са ревютата и копирате линка.
Вземане на ludoCID и LRD от Google Maps за ревю
4. Махате ,1 отзад (може да е и нещо друго) и дописвате ,3,5
5. Успех! Нашия финален линк е следния
https://www.google.bg/search?q=%D0%90%D0%BB%D0%BE%D1%85%D0%B0+(Aloha+Bulgaria),+ul.+%22Pirin%22+77%D0%91,+1680+Sofia&ludocid=1486783925008404561#lrd=0x40aa84ea6165b697:0x14a21e1a3be31051,3,5
6. Резултат от посещението на горния линк
Форма за писане на ревю към Google Business Page

Трик N:1 – горния линк можете да го залепите нейде из футъра на сайта със някаква интересна картинка „Напишете ни ревю във Google“

Трик N:2 – линка също така може да бъде скъсен със използване на goo.gl и да се закачи един Analytics Event за отчитане на кликовете към него.

ВАЖНО: Моля не използвайте този метод за лоши цели. Видовден винаги идва!

Последният войнишки император

Тъй като напоследък не съм се разписал, но непрекъснато чета това и онова е време да започна да ги складирам нейде. И времето дойде.

Последният войнишки император – част 1
Последният войнишки император – част 2
Последният войнишки император – част 3

Общо взето се чете на един дъх и е много завладяващо. Няма да ви развалям удоволствието със разкрития какво се случва. Само става въпрос за иманяри и императори.

Restarting Firefox

Току-що открих как може да се рестартира Firefox без да се загуби нищо.

  1. Натискате Shift-F2. За Mac е Fn-Shift-F2.
  2. Във конзолата която излиза пишете restart

Това е.

zlib extraction

Снощи докато чистех един сайт от вируси намерих интересна директорна структура която просто не и беше мястото там (директория със транслации на javascript) със над 9999 файла и един добре обфускиран PHP скрипт. Разбира се любопитството ми проработи и преглеждането на файловете със шестнадесетичен редактор не даде никакъв резултат – или бяха криптирани или компресирани. Общото беше че всички файлове започваха със 0x78 0x9c. Опитите да видя какво е със file (*nix инструмент показващ типа на файла) не дадоха резултат. Но търсачките веднага разконспирираха, че това е zlib компресиран поток. Това ми разпали още повече любопитството да видя какво има във горните файлове.

Опитах да ги разкомпресирам със gunzip. Не се получи защото gzip използва zlib за компресия, но тогава файла започва със 0x1f 0x8b 0x08 и след няколко байта е самия zlib поток. Мързеше ме да си компилирам програма за разкомпресиране на zlib, можех да спретна и нещо на скриптов език. Но бях убеден че има и далеч по-лесен начин.

ИМА! Цялата магия се осъществява със следния „магически“ ред:
printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" |cat - zlib.raw |gzip -dc
което ми спести няколко цени минути. Има и още един подобен трик със openssl (и двата правят едно и също просто разликата е във самия синтаксис):
openssl zlib -d < zlib.raw
openssl zlib -d -in zlib.raw

Резултата – видях съдържанието на файловете което беше вече първото реално доказателство за наличие на пробив във сайта. И за пореден път се убедих че от *nix-а по-голямо няма.

W3TC and Yoast SEO sitemap problem

Проблем със генерирането на sitemap под WordPress

WordPress е много хубава CMS система и работи out-of-box. Но за да работи още по-добре се слагат разни плъгини, уиджети, модули и други благинки. Сега ще ви покажа как 2 перфектни и много известни плъгини се сбиват и правят живота ви със една идея по-труден дори при генерирането на един прост sitemap. От дълго време ползвам W3TC както и Yoast SEO. И двата плъгина са лидери във своята област и всекидневно се използват от милиони блогове. За съжаление има малка уловка при тях която се отразява на XML sitemap-a.

От известно време забелязах че сайтмапа ми веднъж се появява така:

correct-yoast-seo-sitemapдруг път така:

broken-yoast-seo-sitemapПоради липса на време (и интерес) не обърнах внимание защо и как се получава това. Отделно роботите продължават да ми посещават сайта без проблем, все едно няма такъв. Обаче има проблем: веднъж когато работи сайта ми връща text/xml, друг път text/html. В момента работя разни неща за проверка на sitemap и не ми трябва просто някакъв сайтмап, ами ми трябва перфектният сайтмап.

След 30 минутно разследване се оказа че когато съм логнат винаги виждам нещата перфектно независимо колко пъти ги презаредя. Когато изляза и почистя W3TC кеша ги виждам перфектно веднъж като xml, след което при презареждане ми се сервират html файлове. Което е сигурен признак, че проблема е нейде във W3TC.

Малко предистория
W3TC има няколко режима на работа от които на мен най-ми харесва Disk: Enhanced. Във този режим готовите страници се записват на диска и със няколко ловки пренасочвания със .htaccess или nginx правила се достъпват. Това е един от най-добрите режими защото веднъж след като WordPress и PHP генерират страницата повече не се изпълнява нито ред код от тях. На практика дори WP/PHP не знаят че страницата е достъпвана след като я генерират. Единственния вариант да се достъпи е когато човек се логне или когато кеша се инвалидира. Другия вариант е Disk: Basic, но там веднъж след като се генерира страницата и се записва после достъпа пак минава през WP/PHP. Там плюса е че не се извикват всички плъгини и модули за целта и направо се връща готовата страница. На практика плъгина Hyper Cache Extended на Marto Lazarov прави същата функционалност. Другия подобен плъгин е WP Super Cache на Donncha O Caoimh, но той е малко по-комплексен и съчетава едновременно Basic и Еnhanced.

Сега Disk: Enhanced след като генерира файла го обслужва със серия правила за web server-a. Но проблема е че по дефиниция той приема че всички кеширани файлове са text/html докато във моя случай трябва да връща text/xml. За да бъде хаоса пълен тези файлове не съществуват физически на диска а WordPress ги виртуализира през едно негово API. Yoast SEO ги генерира от базата данни и ги връща на клиента. Затова и W3TC ги прихваща.

Разбира се W3TC има правила при които може да се изключи файл от кеширането. При мен просто във Performance -> Page Cache -> Never cache the following pages:

sitemap_index\.xml
main-sitemap\.xsl
post-sitemap\.xml
page-sitemap\.xml
category-sitemap\.xml
author-sitemap\.xml
post_tag-sitemap\.xml

При вас разбира се може файловете малко да се различават. Затова отворете sitemap_index.xml и добавете във горния списък необходимите файлове.

Разбира се всичко зависи от настройките на плъгините и на практика ставате жертва на обстоятелствата. И двата плъгина работят чудесно по отделно, но при определени настройки нещата се чупят когато са заедно. Разбира се това работи във моя случай. Обаче ако сте активирали минифицирането и конкатинирането на файловете е напълно възможно също да счупите генерирането на сайтмап.

Извода е, че колкото по-голям и комплексен е даден плъгин толкова по-голяма е вероятността да повреди нещо друго. И винаги проверявайте какво се случва след плъгините. Понякога малки и незначителни на вид неща имат катастрофални последици.