«на русской сцене мы удивляем друг друга тем, что вообще что-то делаем», © manwe
(из статуса SCRIMERS на demoscene.ru/forum)

Пятиминутка мета: в этом тексте вам, котятки, предстоит прочитать о том, как потратить свое время совершенно неэффективно с точки зрения отношения размера полученного продукта к потраченным времени и усилиям.
Предположим, что мы хотим сделать что-нибудь эдакое, например, интру размером до 4кб, но мы нищеброды, и у нас нет денег на виндовс и видеокарту с шейдерами, поддерживающими ветвления. Или мы просто не хотим брать стандартный набор из apack/crinkler/sonant/4klang/боже-что-там-еще-есть, делать очередную «смотрите все! я тоже умею рэймарчинг дистанс филдс!» и теряться среди десятков-сотен таких же. Ну или же мы просто любим выпендриваться как попало в надежде, что девочки на нас наконец-то обратят внимание.

В общем, не важно. Пусть у нас просто есть какой-нибудь линукс со слабой видеокартой и вся юность впереди. Попробуем со всем этим теперь создать запускаемый файл размером не более, скажем, 1024 байт, который при запуске умудрялся бы каким-нибудь образом создавать и показывать пользователю что-нибудь (эдакое).

Так бывает что сервер зависает, но к нему не подключена ни клавиатура, ни монитор.

У меня нет лишнего монитора, и обнаружив, что сервер не отвечает по сети,
снимать монитор с моего компьютера и подключать к серверу в кладовке нет никакого желания и сил.

В Linux есть такая возможность ядра как Netconsole.
Netconsole позволяет послать сообщения от ядра на удаленный компьютер.

Для настройки netconsole нужен другой (постоянно включенный) компьютер который примет сообщение по сети.

В последнее время на хабре появилось довольно много статей, посвященных астериску и во всех статьях авторы для описания dial plan'а используют стандартный extensions.conf. Я не буду описывать здесь формат записи в extensions.conf, а лишь постараюсь кратко описать его различия с конфигурационными файлами в формате AEL(extensions.ael), которых на самом деле совсем немного, а вот удобств ael добавляет значительно. В дальнейшем, для удобства, dial plan, описанный в extensions.conf буду называть «обычным» форматом, ну а ael — соответственно ael. Давайте рассмотрим пример простейшего dial plan'a в обычном формате:
;

[internal]
exten => s,1,Answer                                                             
exten => s,n,Background(someivr)
exten => s,n,Read(intgroup,,3)
exten => s,n,Goto(${intgroup},1)
exten => XXX,1,Dial(SIP/${EXTEN})
exten => XXX,n,HangUp

А вот так этот же контекст будет выглядеть в синтаксисе ael:

context internal {
	s=> {
		Answer;
		Background(someivr);
		Read(intgroup,,3);
		Goto(${intgroup},1);
	}
	XXX => {
		Dial(SIP/${EXTEN});
		HangUp;
	}
}

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

Универсального решения в данном вопросе нету, просто есть некоторые аспекты, которыми следует руководствоваться при выборе схемы разбивки.

Суть такова — есть Debian + Xen 4.1.1, туда надо установить FreeBSD. Краткая справка, начиная с FreeBSD 8.0 умеет работать в Xen в режиме PV, до этого был доступен только режим HVM и только если ядро включает в себя нужные драйверы и опции. Так же, только i386 версия работает в режиме PV.

У одного молодого развивающегося провайдера на заре становления организации доступа для физ. лиц была принята следующая архитектура для сети:

• IPoE
• привязка порт-ip
• выдача адресов по DHCP (опция 82)
• маршрутизирующий сервер на Linux (CentOS)

По мере роста абонентской базы все проблемы из первых трех пунктов решались успешно. А с последним прогнозировались небольшие проблемы:

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

Представим что у нас есть виртуальная машина на LVM разделе, внутри которой так же есть LVM разделы. К примеру CentOS, при установке, по умолчанию, создает LVM-based разделы, за исключением /boot.

Задача:

добраться до данных в этих разделах с родительской машины.

1. Постановка задачи

Дано
Debian-сервер «из коробки» (установлен из дистрибутива)

Задача
Организовать работу нескольких проектов на сервере, чтобы люди, которые ими занимаются, не имели доступа к соседним проектам:

• Ограничить возможность обзора файловой системы определенной папкой для пользователя проекта.
• Ограничить возможность запуска бинарников пользователями
• Ограничить возможность открытия портов на сервере (нужно как-то по другому сформулировать)
• Автоматизировать добавление пользователя в систему: создание папки, конфига apache, пользователей mysql или postgres

Лирическая часть

Кто из нас в детстве не разбирал игрушки, чтоб посмотреть, что же там такое внутри. Я не был исключением. Прошло всего несколько лет, и одной из игрушек стал линукс. Из абстрактного желания «сломать и посмотреть» оно формализовалось в несколько вполне конкретных задач, одной из которых стала найти некую отправную точку — минимальное нечто, которое бы грузилось и давало шелл. Пару раз я начинал собирать lfs, но до конца так и не дошел. Прочел несколько статей про разработку embedded, но там все было чересчур серьезно и по-взрослому: после предложений сооружать окружение для кросс-компиляции под различные архитектуры и удаленной отладки в панике отключал интернет. Пересмотрел несколько mini-livecd, но все они или мегадревние (ядро 2.4 и ниже) или обязательно с графикой и DE, что никак не вписывалось в мое представление об идеальном минидистре для опытов.
И вот не так давно я случайно узнал, что то, что я ищу, называется initramfs и лежит у меня под носом.

Есть программа iperf, которая позволяет проверять скорость интерфейсов (у меня на тестах из 10G интерфейса она выжимала 9.37 Гбит/с).

Пакет (в дебиане и убунте) так и называется — iperf.

Применение очень простое: на одном сервере запускаете iperf -s X.X.X.X (свой собственный адрес сервера, на котором слушать). Можно запустить просто iperf -s, тогда слушать будет на всех интерфейсах.

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

Пример: сервер имеет адрес 192.0.2.1, клиент 192.0.2.200. На сервере запускаем iperf -s 192.0.2.1 на клиенте iperf -c 192.0.2.1.

Для того, чтобы сделать много байтов (привет хостерам с соотношениями) нужно просто указать опцию -t (время в секундах). Многие гигабайты трафика в нужном направлении вам обеспечены. С учётом текущих тарифов для дома — можно даже с домашней машины, за 3-4 часика можно выправить любое соотношение с минимальной нагрузкой как на сервер, так и на клиента.

Наблюдая выводы таких команд, как top, htop, uptime, w и, возможно, других, пользователь наверняка обращал внимание на строку load average:

Прочитал сегодня на хабре перевод статьи Распределение символов в паролях. Захотелось провести свой небольшой анализ. Интерес для меня представляют длины паролей, первые символы паролей и используемые в паролях биграммы (пар смежных символов). А также в статье будет рассмотрен алгоритм улучшенного полного перебора паролей.

В .bashrc можно описывать функции.

К чему это я? Если вам не хватает alias, не обязательно писать однострочный скрипт.

В статье будут описаны нюансы настройки IP-телефона Cisco на примере цискофона 7942G.
Итак, если вы присматриваетесь к VoIP-устройствам Cisco серии 79XX, то добро пожаловать под кат.

Привет, Хабрсообщество!

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

Как и было обещано в соседней теме, где рассказывался велосипед, выкладываю описание алгоритма SRP RFC2945 — способе регистрации и аутентификации пользователей безопасным образом по небезопасному каналу. Вот только в процессе подготовки статьи я обнаружил более свежую версию протокола, SRP-6, вместе с реализацией, в связи с чем решил выбросить свои архаичные наработки по SRP-3, и просто дать ссылки на имплементацию новой версии.

Все мы слышали анектоты про мужиков, которые напильниками допиливали память чтобы в материнку влезла, не раз радовала нас эта шутка в разных вариациях… Однако, понадобилось мне тут на досуге кое-что посчитать (жесткачь полный, но об этом отдельная история) — в материнке у меня 3 штуки PCI-E x16 (и 2 x1), но нижние 2 стоят так, что туда только одну карту поставить можно (двухслотовую), как ни крути. А нужно 3 — на двух считать, а на третьей чтобы десктоп не тормозил.

Тут мой взор и упал на старичка, не раз меня выручавшего — nVidia 8400GS (как сейчас помню, хотели мне продать 8500GT, т.к. быстрее, но я был стоек :-) ), остается взять напильник, и попробовать запихнуть в x1 слот…

На хабре уже была статья (про то, как в слоте прорезается щель, и карта влазит) — но у меня чипсет с радиатором не дал бы так просто отделаться (также там не было про проблемы с определением карты биосом)… Потому я решил пойти единственно правильным путем — не курочить материнку, а срезать с карты разъем :-) Поехали!

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

Однако динамический контент довольно плохо сочетается с большими нагрузками. Для веб-сервера, отдача статической странички — намного более простая задача, чем запуск кода, который сгенерит эту страничку динамически. В некоторых случаях может выручить прегенерация всех возможных вариантов странички, но это не спасёт, если их слишком много, или страница обновляется слишком часто.

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

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

Этот вариант иногда неизбежен, например когда сервера в разных датацентрах. Но если сервера (новый и старый) стоят в соседних стойках, то можно просто перенести ОС на новую железку а старую сразу погасить. О том как это сделать я и напишу небольшую статью-чеклист. Итак поехали!

Здравствуйте, хабрасообщество.

Хотелось бы осветить переход сети на IPv6, так как эта теме слабо освещена, тем более на русском языке. Сначала посмотрим на то, как выглядит наша сеть до перехода: