Одминский блог

Как узнать свой номер мобильного телефона

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

Но в эти выходные столкнулся с тем, что у клиента уволилось несколько человек, которые и унесли с собой данные о номере рекламного телефона. Вся загвоздка этого номера была в том, что он был заблокирован для исходящих звонков и работал только на прием, ну а доки от сим-карты естественно были потеряны за ненадобностью еще в прошлой жизни.

Так что встала задача определить его номер на основе сервисных USSD запросов оператора. Что и было сделано, но заодно и разжился запросами всех остальных основных операторов. Надо отметить что все USSD запросы идут в форме диалога, так что после набора комбинации нажимаем вызов, а дале придется несколько раз пересылать различные циферки, следуя ответам оператора.

Для Мегафона:
*151#
Такчже если звонки разрешены, можно набрать в суппорт оператора: 0500.

Для МТС:
*123#
Также можно позвонить в службу поддержки МТС: 0887.

Для Билайн:
*110#
Опять же можно отзвонить в поддержку оператора, по номеру: 0611.

Теги: Сети

Новый хостинг, новые проблемы

Переведя сайты на новый VPS сервер, я со спокойной совестью отправился на дачу, где собственно выйдя в середине субботы в инет, обнаружил что мои сайты, включая cpanel, снова находятся в глубоком дауне, что повергло меня в уныние, так как по воспоминаниям о Webitellects следовало писать в поддержку и ждать перегруза VPS. Но как оказалось, все сервисы VPS сервера работали исправно, за исключением апача. Но самое радостное во всем это был тот факт, что у Burst.NET, помимо контрольной панели хостинга на выбор из cpanel, Direct Admin или Plesk, также предоставляется управление VPS сервером уже на уровне гостевой виртуальной машины OpenVZ, так что залипоны VPS можно вылечивать собственноручно, даже не обращаясь к службе поддержки.

Оттуда же можно создавать резервные копии, смотреть загрузку, перегружать или вырубать VPS сервер. Так что я спокойно перегрузил сервак и отправился по своим делам. Но приехав домой в понедельник обнаружил, что мои сайты работают очень странно, так как на них не отображались теги и категории. То есть посты, видео и прочее на месте, а вот теги и категории не привязаны к системе, причем движок WP говорил что категории отсутствуют.
Естественно что я решил что проблема с базами, так что стал смотреть что у меня происходит на Webintellects, и как оказалось, что не смотря на тот факт что я не оплатил хостинг еще в субботу, он продолжает фунциклировать. Так что я начал не спеша вытягивать сайты со старого хостинга, пытаясь понять что же происходит на новом.

Но оказалось, что проблема не только с категориями и тегами на сайтах, а еще и с квотами на диске, ибо я не мог закачать бэкапы на новый VPS сервер, который отвечал мне “Disk quota exceeded“, а также cpanel не пускавшая меня вовнутрь со следующей ошибкой: “Internal Server Error 500,  more than 400 attempts to create a session failed“.

Кароче полный трындец по всем фронтам.

Для начала я попробовал отрубить квоты, которые вроде не врубал при установке и настройке cpanel, но после ввода команды отключения квот
# quotaoff -vaug
ругань продолжалась, не смотря на то что система рапортовала об их отключении.
То есть надо было отрубить их в cpanel или же на уровне вируталки, но поскольку cpanel у меня не грузилась, то я стал рыть в сторону ошибки “Internal Server Error 500,  more than 400 attempts to create a session failed”. Рылся не особо долго, ибо ошибка оказалась чуть ли не стандартной и была описана на сайте cpanel- превышение числа инодов, что подтвердилось командой:
# df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/simfs           600000  600000 0   100% /

Как говорится- приплыли, ибо этот параметр задается уже на уровне управления VPS , или же переносом инодо-генерящего приложения на другой диск- обычно это логи почтаря или какого нить еще высконагруженного сервиса.

Но поскольку у меня раздел в системе был только один, то я накатал тикет в суппорт, который и реанимировал все в течении 2 часов, подняв лимит нодов в несколько раз. После чего оставалось только перезапустить exim, который выпал в ошибку от невозможности записи на диск, и начать работать.
Как оказалось- все теги и категории не работавшие после переезда, также заработали после увеличения лимита разрешенных инодов.

Теги: хостинг

Переезд на новый хостинг Burst.NET

Ну что же- продолжаю мою тему с терзаниями вокруг хостингов, в связи с чем я все таки остановил свой выбор на довольно интересном штатовском хостинге Burst.NET, предлагающем дешевые VPS севера, чья стоимость начинается от 6$. Поковырявшись в тарифах, я нашел себе интересный планчик за 42$ с 2,5Ghz, 2,5Gb оперативки, 150Gb дискового пространства, и 2Tb ежемесячного трафа (с включенной сюда ежемесячной платой за аренду cpanel), при том что за те же деньги я столовался в Webintellects на втрое меньших мощностях.

В итоге я в течении двух дней пытался списаться со службой суппорта Burst.NET через систему тикетов, на предмет выяснения – помогут ли мне инженеры хостинга с переносом моих сайтов с VPS сервера Webintellects на новую площадку; но в ответ была лишь тишина. Поэтому я сделал ход лошадью- просто взял аналогичный вебинтеллектовскому VPS сервер за 22$ (из которых 12$ пришлось на cpanel, о чем я ни разу не пожалел в последствии, но об этом ниже) и решил что перенесу все на него, после чего подниму уровень VPS до выбранного мною.

Оказалось что со службой поддержки можно было связаться не только через систему тикетов, но и через почту, просто отписав им на служебный мейл- и как оказалось- это наиболее действенный способ связи с суппортом хостинга, так как на письма они отвечают в течении 30-40 минут. Ответ был- нет, переезд ваши собственные проблемы. Хотя оно и понятно, за такие то башли. Возможно трансфер обеспечивается суппортом, если вы приобретаете полноценный менеджмент за 45$ в месяц, но на мой взгляд  такой уровень поддержки имеет смысл брать на серьезный дедик или верхнюю ступень VPS планов. В итоге поматерившись на суппорт, я решил что с оказией перевезу свой сервак сам, благо у меня там хостилось от силы 10 сайтов.

В итоге седня мне с середины дня позвонил коллега, чьи доменные зоны также крутились на моем серваке и поведал мне историю о том, что мои серваки не отдают ничего, что естественно могло означать только одно- мой VPS сервер на площадке Webitellects снова накернился. Так что добравшись до стационара, я опять же нагнул хостинг и решил, что ХВАТИТ. Пришло время для переезда.

Естественно ручной переезд дело унылое и долгое, так что я начал с маленького и никому не нужного сателлита, ибо его падение было бы незаметно ни для кого. Созда резервную копию, скопировал её себе на комп, перенес на новый VPS сервер, после чего полез изучать cpanel, а точнее её VPS вариант WHM.

И тут то оказалось, что в cPanel предусмотрена отличная функция переноса сайтов между cpanel и другими консолями управления, которая на автомате трансферит информацию с одного сервера на другой на уровне аккаунтов: левый фрейм управления -> Transfers -> Copy an account from another server. Там в принципе вариантов для заполнения не так много, единственно что в процессе переноса, стоит включить галку Change DNS on Source Server to Point to Local Server для того чтобы видеть, что сервера на новом хостинге уже фурычат. Переносим все под рутовыми правами доступа для ускорения процедуры доступа.

Собственно в течении часа я перенес все сайты, кроме основного, который занимает порядка пяти гигов дискового пространства, так что он трансферился порядка 2+ часов, так что к ночи у меня уже все уверенно работало на новом VPS хостинге.

Так что основная проблема, с которой я столкнулся на данный момент в процессе знакомства с новым хостингом Burst.NET заключается в том, что парни не помогают при переезде, предоставляя пользователю решать эту проблему самому (и как понятно- это проблема решается малой кровью, с помощью cpanel), а также тот факт что служба суппорта очень неспешно реагирует на обращения- среднее время реакции 2-3 часа.

Теги: хостинг

Очередные разборки с хостингом

Видимо у меня все не может быть слишком хорошо в делах, так как не успел я толком разобраться с DDOS-атакой на свой туристический блог, как у меня начались проблемы на основном сайте и десятке всяких кривых поделок, что в данный момент хостятся на Webintellects.

С полгода назад, когда мой туристический сайт тока вышел на уровень 250+ уников в день, мой VPS с 256Mb на бору, стал эпизодически залипать, и в процессе натягивания суппорта на кукан, я получил VPS с 1Gb на борту, за те же самые 35$, что я и платил за 512Mb, но проблему это не решило, поэтому я перенес сайт на Cyberwurx, где он успешно и хостится последние полгода. При этом помимо нормальной работы блог на ежедневном трафике уже в ~500 уников, на этом же акке крутится порядка 5 сателлитов, делающих еще пару сотен уников в день. И при этом все резво шуршит и летает.

А вот Webintellects дал знать о себе на той неделе, когда в четверг у него благополучно вышла из строя сетка, после чего мои сайты были не доступны в течении часа или более. Затем через день пошли не понятные пропажи сайта, при этом VPS просто исчезал, то есть все сервисы не отвечали- не только веб, но и пинги, ssh и прочее. На второй раз, уже на этой неделе, я разосрался с суппортом, так как они стали мне лить в уши про overload и то, что я могу посмотреть сам по логам, что у меня там происходит. При том что в логах была тишина, и использование памяти и cpu не превышало 20-25%. По итогам гневной переписки мне сменили инженера и новый чел пообещал, что будут мониторить мой сервак на предмет выяснения причин залипонов.

В итоге мониторили, аж до середины сегодняшнего дня, когда я опять, попытавшись зайти на свой сайт, обнаружил что он снова полностью залип. После чего я накатал полувопрос, с просьбой рестартнуть мой сервак. Прошло полчаса, после чего я написал вторую заявку. Еще через час, не получив ответа и работающего VPS, я накатал матерную телегу на предмет вопроса о том, каким же надо быть мудланом, что не суметь перегрузить факин VPS сервер. И что же- сервак заработал через 5 минут. То есть “через мать” бурги все таки понимают, но в данный момент нахожусь в состоянии поиска нового VPS, ибо такие расклады меня естественно совершенно не радуют.

Нашел парочку хостингов и в данный момент терзаю сейлов на предмет выяснения всех подробностей, ибо помимо того что хочется за минимум денег, максимум фич, так еще и чтобы все перенесли умные и ловкие парни, ибо самому переносить и настраивать 15 сайтов нет особого желания.

Теги: webintellects, интернет, хостинг

Вторая корректировка PR

Седня ближе к вечеру приключилась очередная корректировка PR, в ходе которой часть проектов лишилась единички пыра, другая же часть, включая и этот сайт, наоборот получила по единичке. В общем на тех проектах что я заметил, ситуация сложилась следующим образом (первая цифра показывает что было до первого апа от 27.06, последняя изменение сегодня):

2 -> 1 -> 2 -> 1
2 -> 1 -> 2 -> 1
0 -> 4 -> 1 -> 2
1 -> 5 -> 2 -> 3

Остальные пыреносцы остались без изменений, хотя очень странно, так как на основном моем сайте отобрали древний как говно мамонта PR2, дав вместо него единичку, которая так и осталась висеть на сайте.

Но при этом по сайтам щедрой рукой рассыпали PR1, выдав всем постам, категориям и тегам, и что самое смешное- на этом сайте, и на паре других, выдали PR аналогичный морде сайта, всем постам что на момент 29 июля находились на морде. Так что мне сдается, что очередная корректировка не за горами. А значит этому сайту, вполне вероятно дадут уже PR3, ибо он его заслуживает.

Так что на данный момент картина следующая:
27.06 – апдейт Page Rank
18.07 – первая корректировка Page Rank
04.08 – вторая корректировка Page Rank

ждем третью???

З.Ы. По итогам утренних разборов выяснилось, что это была прелюдия к очередному апу PR, который собственно и расставил все точки на йо.

Теги: google, pr, поисковики

Оптимизация работы ipf и ipnat

В дополнение ко вчерашней статье о настройке фаервола, хотел бы упомянуть также некоторые моменты касаемые эксплуатации программного фаервола на базе пакета ipfilter или ipf, которые могут всплыть в процессе работы с указанным фаерволом. А также несколько фич, используя которые можно оптимизировать работу фаервола и механизма NAT.

После внесения изменений в правила фаервола, данные правила можно применить без перезагрузки фаервола, просто перечитав файл правил, причем это может быть как дефолтовый файл, так и рандомный:
# ipf -Fa -f /etc/ipf.rules
где,
-Fa сброс всех правил фаервола.
-f указывает фаайлец с новыми правилами фаервола (так что не ошибитесь, ибо как вы помните фаервол мы собираели с блоком по умолчанию)

так же можно перечитать и правила ipnat, используя команду
# ipnat -CF -f /etc/ipnat.rules

Полную статистику работы фаервола с момента загрузки системы  можно просмотреть командой
# ipfstat
При этом ключ -ih выдаст количество входящих пакетов, со статистикой прохождения или блокировок с попаданием в правила,
ключ -oh выдаст туже статистику для исходящих пакетов. Это отличное подспорье в оптимизации работы фаервола, путем помещения наиболее часто используемых правил фаервола наверх таблицы.
Обнулить эту статистику можно командой
# ipf -Z
Просмотреть проходящие пакеты в режиме реального времени, можно командой
# ipmon
собственно её вывод и пишется в логфайл.

При использовании ключа  -n адреса и порты будут преобразованы в хостнеймы и сервисы, что довольно удобно для мониторинга того- кто где сидит в данный момент,
а при использовании ключа -x данные проводящих пакетов будут выводиться в hex-коде, что тоже может доставить много интересных минут сисадмину.
Используя команду ipnat можно просматривать таблицу состояния адрес трансляций:
# ipnat -l выведет все открытые на данный момент трансляции адресов
# ipnat -s выводит статистику работы адрес трансляции
# ipnat -F обнуляет все активные соединения из актуальной таблицы адрес трансляций

У ipnat есть, по умолчанию вшитое, количество возможных открытых сессий, и проверить его можно командой:
# ipf -T list | grep nattable
и вероятнее всего вы получите ответ что максимальное число открытых сессий 30к, что для большой сети не так уж и много, так что увеличить это число можно добавив в файл rc.conf следующую строчку:
ipfilter_flags=”-D -T ipf_nattable_sz=10009,ipf_nattable_max=200000 -E”
и перегрузив ipfilter, тем самым увеличив число сессий до 200к.
Также если ваш ipnat.rules предполагает более 127 правил, которые установлены по умолчанию, вам необходимо  также добавить в переменную ipfilter_flags файла rc.conf ключики ipf_natrules_sz=1023,ipf_rdrrules_sz=1023
Еще один момент касаемый уменьшения таймаута TCP сессии, что также позволит оптимизировать работу NAT, так как многие сессии сохраняются в таблице не смотря на то что соединение уже давно закончилось. Для этого добавляем во флаги, также ключи fr_tcptimeout=180,fr_tcpclosewait=60,\
fr_tcphalfclosed=7200,fr_tcpidletimeout=172800
В итоге на выходе в rc.conf имеем следующее выражение:
ipfilter_flags=”-D -T ipf_nattable_sz=10009,ipf_nattable_max=200000,fr_tcptimeout=180,\
fr_tcpclosewait=60,fr_tcphalfclosed=7200,fr_tcpidletimeout=172800,\
ipf_natrules_sz=1023,ipf_rdrrules_sz=1023 -E”

Теги: FreeBSD, IT безопасность, настройка системы

Настройка программного фаервола на базе FreeBSD

Наконец то дошли руки, до воссоздания манула по настройке фаервола на базе системы FreeBSD, который помимо стабильности, надежности и безопасности отличается еще одним немаловажным, для многих компаний, качеством – это бесплатный фаервол. Большая часть настроек выработана годами опытной эксплуатации, так что они означают уже припомнить довольно сложно, да и к тому же  займет еще полстатьи, так что вероятнее всего часть настроек, которые я не рассматривал в данной статье, я распишу несколько позднее.

Переведем данное мероприятие сразу же в плоскость экономической выгоды для сисадмина, ибо на мой взгляд, настройка программного брандмауэра находится на втором месте, после лечения компьютера от вирусов, и перед восстановлением данных- по соотношению заработанных средств к затраченному времени. Поскольку на настройку программного фаервола на базе FreeBSD тратится от 6 до 10 часов, с момента как вы включили пустую машину, до момента когда вы можете уже включать данный сервер в разрез сети. Естественно, что поднять сам фаервол займет от силы полтора-два часа на создание и обкатку правил: большую часть времени занимает пересборка и апгрейд системы.

Также надо отметить, что данный пост повествует исключительно о настройке фаервола, а не унифицированного средства защиты с потоковым антивирусом и IPS, о которых я возможно поговорю позднее.

Итак- настраиваем программный фаервол на базе FreeBSD.

Читать полностью »

Теги: FreeBSD, IT безопасность, настройка системы