November 2019

S M T W T F S
      12
34 5 678 9
10111213141516
17181920212223
24252627282930

Style Credit

Expand Cut Tags

No cut tags

March 1st, 2012

dil: (Default)
Thursday, March 1st, 2012 12:00 pm

Американцы из некоего First Tennessee банка подтверждают репутацию тупоголовых идиотов.

Какой-то пидарас зарегистрировался в их банке, указав мой адрес электронной почты. На первое полученное от них письмо я ответил, сообщив, что я не их клиент. Поблагодарили, попросили уточнить, на какой именно адрес я это письмо получил (в гуглопочте точки в адресе игнорируются, поэтому одному почтовому ящику могут соответствовать разные адреса), приняли к сведению.

Но адрес зачем-то подписали на свою рассылку. После многократных вежливых просьб и невежливых требований наконец ответили:

“A request has been submitted to remove your email from our distribution lists. It can take up to 30 days before you stop receiving all emails.” Видимо, приходящий админ их посещает раз в месяц, а остальным тупость не позволяет удалить адрес без него.

И заодно “If you have an immediate question or concern please contact our customer service department at 800-609-3573.”

Написал им, что я вообще в другой стране, и если я позвоню по такому номеру, то в их customer service department никак не попаду.

И знаете, что они ответили? Правильно:

“Thank you for your inquiry regarding phone number.
We do apologize for any inconvenience. You may dial 800-382-5465 to reach Customer Service.”

Ну тупы-ы-ы-ые, иначе не скажешь.

P.S. Попутно посылаю луч поноса разработчикам гуглопочты, которые до сих пор ниасилили довольно простые функции forward as attachment и forward multiple emails. Приходится всё вручную копировать.

Оригинал этой записи в личном блоге.

dil: (Default)
Thursday, March 1st, 2012 02:15 pm

При обследовании одного сервера на предмет используемой версии OpenSSL обнаружилось, что… никакой:

# ldd apache/modules/mod_ssl.so |grep libssl
	libssl.so.1.0.0 => not found

Апач был собран афроадминистраторами из исходников. Но при сборке маршрут к библиотеке явно не указали, и в ld.so.conf тоже не написали, вот она и не находится. Тем не менее, апач таки успешно запускается, и SSL в нём каким-то чудом работает.

Дальнейшее препрарирование показало ещё более прекрасное:

# ldd apache/modules/libphp5.so |grep libssl
	libssl.so.1.0.0 => /opt/openssl/lib/libssl.so.1.0.0 (0x00002ad00e36d000)
	libssl.so.6 => /lib64/libssl.so.6 (0x00002ad0101b3000)

PHP, понятное дело, тоже был собран афроадминистраторами из исходников.

А теперь вопросы:
Вопрос 1, достаточно простой: КАК они умудрились собрать PHP с двумя разными версиями одной библиотеки одновременно?
Вопрос 2, посложнее: а нафига они это сделали?
Вопрос 3: а всё-таки как апач находит библиотеку при загрузке mod_ssl? Никаких LD_PRELOAD и LD_LIBRARY_PATH в запускающем скрипте апача нет, я проверял и в самом скрипте, и в environment’е запущенного апача.
Вопрос 4: и что надо с такими администраторами после всего этого сделать?

Оригинал этой записи в личном блоге.

dil: (Default)
Thursday, March 1st, 2012 09:21 pm

Пятниццо! Время рассказать о техсуппорте, как я и обещал.

Каким образом _даже_ заключение какого-то там соглашениЕ может защитить от утечки информации — тайна великая есть. Равно как и место, в котором надо будет создавать секретные ключи. Как же эти люди умеют защищать информацию? А вот так:

Read the rest of this entry » )

Оригинал этой записи в личном блоге.
Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме.