Настройка разрешения экрана в Linux

linux-resolution1. Используем cvt для вычисления параметров, которые будем использовать в xrandr:

Пример:

 

2. Используем параметры cvt в xrandr:

(Параметры Hsync и Vsync должны начинаться с заглавных букв).

 

3. Добавляем новый режим «2560×1440» в xrandr:

(Можно заменить Virtual1 на то, что нужно… Посмотреть можно командой xrandr)

 

4. Включить новый режим:

 

Compiling Kernel 3.8 on Debian Testing/Wheezy

linuxNOTE: It seems like series 3.8 has issues with intel (i915) graphics — it occasionally generates kworker threads that causes unresponsiveness as seen by slow mouse and keyboard response when e.g. plugging or unplugging mains power. No issues on e.g. nvidia though.

http://verahill.blogspot.com.au/2013/03/368-slow-mouse-and-keyboard-triggered.html
http://forums.gentoo.org/viewtopic-p-7278760.html
https://bbs.archlinux.org/viewtopic.php?pid=1248190

Post: Kernel 3.8 is out now. Not much to say — the compilation works well using the standard method. The compressed kernel is about 81 Mb to download.

The approach below shows how to compile the kernel on Debian. If you’re interested in a more generic approach, see this post:

http://verahill.blogspot.com.au/2013/02/344-compile-kernel-38-without-using-kpkg.html

NOTE: kernel 3.8 — in contrast to the 3.7 series — now compiles fine on AMD FX 8150.

NOTE: kernel 3.8 plays well with nvidia dkms

Here we go:


You will be asked a lot of questions — how many depends on what version you upgrade from. If in doubt, pick the default answer (i.e. hit enter). If really in doubt, use google.

Then continue:


Do

if you want to make any specific changes to the kernel (e.g. add support for certain devices)

Then continue:

As usual 4 is the number of threads you wish to launch — make it equal to the number of cores that you have for optimum performance during compilation (more about that here).
The build takes around 20 minutes on a four-core intel i5-2400 with -j4, and 14 minutes on an fx-8150 with -j8 (96 minutes with -j1).
Install:
New stuff/Questions:

Поиск файлов в Linux

find

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

0. Создадим файл размером 10 Мбайт с размером блока 100 Кбайт:

/dev/zero – специальный файл в UNIX-подобных системах, представляющий собой источник нулевых байтов (ASCII NUL, 0x00)

of=file.test – файл который создаем

bs=100K – размер блока, 100 КБайт (может быть: К — КБайт, М — МБайт, — ГБайт)

count=100 – количество блоков

В результате мы получили заданный файл, размером 100К*100=10 МБ

теперь в директории /var/www/ находится файл file1.test размером 52 МБ.

1. Поиск файлов в текущей директории размером больше 10 Мбайт

find – утилита для поиска файлов

. – где ищем. В нашем случае текущей директории (/var/www/* – поиск в директории /var/www/~ — поиск в домашней директории/ – поиск в корне файловой системы$HOME – поиск в домашней директории )

-size +10M – размер искомого файла. Больше 10 Мбайт (b – блок, размером 512 байт, c – байт, w – слово, размером 2 байта, k – килобайт, M – мегабайт и G– гигабайт )

-print – вывод на экран

2. Поиск файлов больше 50 Мб с выводом детальной информации

Усложним задачу и попробуем вывести на экран кроме имени файла еще некоторую информацию о нем.

-type f – тип, который ищем (f – файл, d – директория, l – символичная ссылка, s – сокет, b – блок)

-exec ls -lh {} \; – выполняет команду ls -lh над найденными файлами (вывод содержимого директории)

awk ‘{ print $8 » » $5 » » $1 » » $3″:»$4 }’ – обрабатываем вывод информации командой ls -lh

и выводим более детальную информацию в нужном нам порядке:
$8 – имя файла
$5 – размер файла
$1 – права доступа
$3 – владелец
$4 – группа

3. Поиск файлов заданного размера и определенного имени

-name w* – любой файл имя, которого содержит w*

 

Разделение большого файла на несколько частей

Split

 

Размер частей может иметь суффикс, означающий множитель.

и так далее для T, P, E, Z, Y.

Пример:

Получим много файлов по 100 Мб, с суффиксами part0, part1, part2, part3…:

и т.д.

Чтобы снова объединить все части воедино, можно использовать команду cat:

Утилита cat соберет все файлы, начиная с small.iso.part0.

Основы работы с Git

Введение

Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано.

Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git, а StGit использует Git для управления коллекцией патчей.

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки; изменения копируются из одного репозитория в другой.

Удалённый доступ к репозиториям Git обеспечивается git-daemon, gitosis, SSH- или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.

Основы работы с удаленным репозитарием

git clone — создание копии (удаленного) репозитария

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

Клонируем репозиторий, используя протокол http:

Клонируем репозиторий с той же машины в директорию myrepo:

Клонируем репозитарий, используя безопасный протокол ssh:

У git имеется и собственный протокол:

Импортируем svn репозитарий, используя протокол http:

-s – понимать стандартные папки SVN (trunk, branches, tags)

git fetch и git pull — забираем изменения из центрального репозитария

Для синхронизации текущей ветки с репозитарием используются команды git fetch и git pull.

git fetch — забрать изменения удаленной ветки из репозитария по умолчания, основной ветки; той, которая была использована при клонировании репозитария. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.

git fetch /home/username/project — забрать изменения из определенного репозитария.

Возможно также использовать синонимы для адресов, создаваемые командой git remote:

git fetch username-project — забрать изменения по адресу, определяемому синонимом.

Естественно, что после оценки изменений, например, командой git diff, надо создать коммит слияния с основной:

Команда git pull сразу забирает изменения и проводит слияние с активной веткой.

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

Забрать изменения и метки из определенного репозитория:

Как правило, используется сразу команда git pull.

git push — вносим изменения в удаленный репозиторий

После проведения работы в экспериментальной ветке, слияния с основной, необходимо обновить удаленный репозиторий (удаленную ветку). Для этого используется команда git push.

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

Отправить изменения из ветки master в ветку experimental удаленного репозитория:

В удаленном репозитории origin удалить ветку experimental:

В удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:

Отправить метки в удаленную ветку master репозитария origin:

Изменить указатель для удаленной ветки master репозитория origin (master будет такой же как и develop)

Добавить ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:

Работа с локальным репозиторием

Базовые команды

git init — создание репозитория

Команда git init создает в директории пустой репозиторий в виде директории .git, где и будет в дальнейшем храниться вся информация об истории коммитов, тегах — о ходе разработки проекта:

git add и git rm — индексация изменений

Следующее, что нужно знать — команда git add. Она позволяет внести в индекс — временное хранилище — изменения, которые затем войдут в коммит. Примеры использования:

индексация измененного файла, либо оповещение о создании нового:

внести в индекс все изменения, включая новые файлы:

Из индекса и дерева проекта одновременно файл можно удалить командой git rm:

отдельные файлы:

хороший пример удаления из документации к git, удаляются сразу все файлы txt из папки:

внести в индекс все удаленные файлы:

Сбросить весь индекс или удалить из него изменения определенного файла можно
командой git reset:

сбросить весь индекс:

удалить из индекса конкретный файл:

Команда git reset используется не только для сбрасывания индекса, поэтому дальше ей будет уделено гораздо больше внимания.

git status — состояние проекта, измененные и не добавленные файлы, индексированные файлы

Команду git status, пожалуй, можно считать самой часто используемой наряду с
командами коммита и индексации. Она выводит информацию обо всех изменениях, внесенных в дерево директорий проекта по сравнению с последним коммитом рабочей ветки; отдельно выводятся внесенные в индекс и неиндексированные файлы. Использовать ее крайне просто:

Кроме того, git status указывает на файлы с неразрешенными конфликтами слияния и файлы, игнорируемые git.

git commit — совершение коммита

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

Если индекс не пустой, то на его основе будет совершен коммит, после чего
пользователя попросят прокомментировать вносимые изменения вызовом команды edit. Сохраняемся, и вуаля! Коммит готов.

Есть несколько ключей, упрощающих работу с git commit:

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

комментируем коммит прямо из командной строки вместо текстового редактора.

внесет в индекс и создаст коммит на основе изменений единственного файла.

git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»

Помимо работы с индексом (см. выше), git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В git данное действие может быть двух видов: «мягкого»(soft reset) и «жесткого» (hard reset).

«Мягкий» (с ключом --soft) резет оставит нетронутыми ваши индекс и все дерево файлов и директорий проекта, вернется к работе с указанным коммитом. Иными словами, если вы обнаруживаете ошибку в только что совершенном коммите или комментарии к нему, то легко можно исправить ситуацию:

  1. git commit — некорректный коммит
  2. git reset —soft HEAD^ — переходим к работе над уже совершенным коммитом, сохраняя все состояние проекта и проиндексированные файлы
  3. edit WRONGFILE
  4. edit ANOTHERWRONGFILE
  5. git add .
  6. git commit -c ORIG_HEAD — вернуться к последнему коммиту, будет предложено редактировать его сообщение. Если сообщение оставить прежним, то достаточно изменить регистр ключа -с:

Обратите внимание на обозначение HEAD^, оно означает «обратиться к предку последнего коммита». Подробней описан синтаксис такой относительной адресации будет ниже, в разделе «Хэши, тэги, относительная адресация». Соответственно, HEAD — ссылка на последний коммит. Ссылка ORIG_HEAD после «мягкого» резета указывает на оригинальный коммит.

Естественно, можно вернуться и на большую глубину коммитов,

«Жесткий» резет (ключ --hard) — команда, которую следует использовать с
осторожностью. git reset --hard вернет дерево проекта и индекс в состояние,
соответствующее указанному коммиту, удалив изменения последующих коммитов:

Если команда достигнет точки ветвления, удаления коммита не произойдет.

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

git revert — отмена изменений, произведенных в прошлом отдельным коммитом

Возможна ситуация, в которой требуется отменить изменения, внесенные отдельным коммитом. git revert создает новый коммит, накладывающий обратные изменения.

Отменяем коммит, помеченный тегом:

Отменяем коммит, используя его хэш:

Для использования команды необходимо, чтобы состояние проекта не отличалось от состояния, зафиксированного последним коммитом.

git log — разнообразная информация о коммитах в целом

Иногда требуется получить информацию об истории коммитов; коммитах, изменивших отдельный файл; коммитах за определенный отрезок времени и так далее. Для этих целей используется команда git log.

Простейший пример использования, в котором приводится короткая справка по всем коммитам, коснувшимся активной в настоящий момент ветки (о ветках и ветвлении подробно узнать можно ниже, в разделе «Ветвления и слияния»):

Получить подробную информацию о каждом в виде патчей по файлам из коммитов
можно, добавив ключ -p (или -u):

Статистика изменения файлов, вроде числа измененных файлов, внесенных в них
строк, удаленных файлов вызывается ключом --stat:

За информацию по созданиям, переименованиям и правам доступа файлов отвечает ключ
--summary:

Чтобы просмотреть историю отдельного файла, достаточно указать в виде параметра его имя (кстати, в моей старой версии git этот способ не срабатывает,
обязательно добавлять » — » перед «README»):

или, если версия git не совсем свежая:

Далее будет приводится только более современный вариант синтаксиса. Возможно
указывать время, начиная в определенного момента («weeks», «days», «hours», «s»
и так далее):

изменения, касающиеся отдельной папки:

Можно отталкиваться от тегов.

Все коммиты, начиная с тега v1:

Все коммиты, включающие изменения файла README, начиная с тега v1:

Все коммиты, включающие изменения файла README, начиная с тега v1 и заканчивая тегом v2:

Интересные возможности по формату вывода команды предоставляет ключ --pretty.

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

Лаконичная информация о коммитах, приводятся только автор и комментарий:

Более полная информация о коммитах, с именем автора, комментарием, датой создания и внесения коммита:

В принципе, формат вывода можно определить самостоятельно:

Определение формата можно поискать в разделе по git log из Git Community Book
или справке. Красивый ASCII-граф коммитов выводится с использованием ключа
--graph.

git diff — отличия между деревьями проекта, коммитами и т.д.

Своего рода подмножеством команды git log можно считать команду git diff,
определяющую изменения между объектами в проекте — деревьями (файлов и
директорий).

Показать изменения, не внесенные в индекс:

Изменения, внесенные в индекс:

Изменения в проекте по сравнению с последним коммитом:

Предпоследним коммитом:

Можно сравнивать «головы» веток:

или активную ветку с какой-либо:

git show — показать изменения, внесенные отдельным коммитом

Посмотреть изменения, внесенные любым коммитом в истории, можно командой git show:

git blame и git annotate — команды, помогающие отслеживать изменения файлов

При работе в команде часто требуется выяснить, кто именно написал конкретный
код. Удобно использовать команду git blame, выводящую построчную информацию о последнем коммите, коснувшемся строки, имя автора и хэш коммита:

Можно указать и конкретные строки для отображения:

Аналогично работает команда git annotate, выводящая и строки, и информацию о
коммитах, их коснувшихся:

git grep — поиск слов по проекту, состоянию проекта в прошлом

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

Поиск слова tst в проекте:

Подсчитать число упоминаний tst в проекте:

Поиск в старой версии проекта:

Команда позволяет использовать логическое И и ИЛИ.

Найти строки, где упоминаются и первое слово, и второе:

Найти строки, где встречается хотя бы одно из слов:

Ветвление

git branch — создание, перечисление и удаление веток

Работа с ветками — очень легкая процедура в git, все необходимые механизмы сконцентрированы в одной команде:

Просто перечислить существующие ветки, отметив активную:

Создать новую ветку new-branch:

Удалить ветку, если та была залита (merged) с разрешением возможных конфликтов в текущую:

Удалить ветку в любом случае:

Переименовать ветку:

Показать те ветки, среди предков которых есть определенный коммит:

git checkout — переключение между ветками, извлечение файлов

Команда git checkout позволяет переключаться между последними коммитами (если упрощенно) веток:

Создаст ветку, в которую и произойдет переключение

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

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

Вернуть файл (или просто вытащить из прошлого коммита) позволяет команда вида:

Вернуть somefile к состоянию последнего коммита:

Вернуть somefile к состоянию на два коммита назад по ветке:

git merge — слияние веток (разрешение возможных конфликтов)

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

Попробовать объединить текующую ветку и ветку new-feature:

В случае возникновения конфликтов коммита не происходит, а по проблемным файлам расставляются специальные метки а-ля svn; сами же файлы отмечаются в индексе как «не соединенные» (unmerged). До тех пор пока проблемы не будут решены, коммит совершить будет нельзя.

Например, конфликт возник в файле TROUBLE, что можно увидеть в git status.

Произошла неудачная попытка слияния:

Смотрим на проблемные места:

Разрешаем проблемы:

Индексируем наши изменения, тем самым снимая метки:

Совершаем коммит слияния:

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

Если же коммит слияния был совершен, используем команду:

git rebase — построение ровной линии коммитов

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

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

Предположим, имеется две ветки, master и топик, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления. Команда git rebase берет коммиты из ветки topic и накладывает их на последний коммит ветки master.

Вариант, в котором явно указывается, что и куда накладывается:

на master накладывается активная в настоящий момент ветка:

После использования команды история становится линейной. При возникновении конфликтов при поочередном накладывании коммитов работа команды будет останавливаться, а в проблемные местах файлов появятся соответствующие метки. После редактирования — разрешения конфликтов — файлы следует внести в индекс командой git add и продолжить наложение следующих коммитов командой git rebase --continue. Альтернативными выходами будут команды git rebase --skip (пропустить наложение коммита и перейти к следующему) или git rebase --abort (отмена работы команды и всех внесенных изменений).

С ключом -i (--interactive) команда будет работать в интерактивном режиме. Пользователю будет предоставлена возможность определить порядок внесения изменений, автоматически будет вызывать редактор для разрешения конфликтов и так далее.

git cherry-pick — применение к дереву проекта изменений, внесенных отдельным коммитом

Если ведется сложная история разработки, с несколькими длинными ветками разработками, может возникнуть необходимость в применении изменений, внесенных отдельным коммитом одной ветки, к дереву другой (активной в настоящий момент).

Изменения, внесенные указанным коммитом будут применены к дереву, автоматически проиндексированы и станут коммитом в активной ветке:

Ключ -n показывает, что изменения надо просто применить к дереву проекта без индексации и создания коммита

Прочие команды и необходимые возможности

Хэш — уникальная идентификация объектов

В git для идентификации любых объектов используется уникальный (то есть с огромной вероятностью уникальный) хэш из 40 символов, который определяется хэшируюшей функцией на основе содержимого объекта. Объекты — это все: коммиты, файлы, тэги, деревья. Поскольку хэш уникален для содержимого, например, файла, то и сравнивать такие файлы очень легко — достаточно просто сравнить две строки в сорок символов.

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

найти разницу текущего состояния проекта и коммита за номером… сами видите, каким:

То же самое, но оставляем только шесть первых символов. Git поймет, о каком коммите идет речь, если не существует другого коммита с таким началом хэша:

Иногда хватает и четырех символов:

Читаем лог с коммита по коммит:

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

git tag — тэги как способ пометить уникальный коммит

Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит, имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик может оставлять на таких тегах собственную цифровую подпись.

Кроме этого в git представленные так называемые «легковесные тэги» (lightweight tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, используются для упрощения навигации по дереву истории; создать их очень легко.

Создать «легковесный» тэг, связанный с последним коммитом; если тэг уже есть, то еще один создан не будет:

Пометить определенный коммит:

Удалить тег:

Перечислить тэги:

Создать тэг для последнего коммита, заменить существующий, если таковой уже был:

После создания тэга его имя можно использовать вместо хэша в любых командах вроде git diffgit log и так далее:

Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо информации, вроде номера версии и комментария к нему. Иными словами, если в комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».

Создать обычный тэг для последнего коммита; будет вызван текстовый редактор для составления комментария:

Создать обычный тэг, сразу указав в качестве аргумента комментарий:

Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от команд для «легковесных» тэгов.

Относительная адресация

Вместо ревизий и тэгов в качестве имени коммита можно опираться на еще один механизм — относительную адресацию. Например, можно обратиться прямо к предку последнего коммита ветки master:

Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам коммитов слияния:

найти изменения по сравнению со вторым предком последнего коммита в master; HEAD здесь — указатель на последний коммит активной ветки:

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

что привнес «дедушка» нынешнего коммита:

То же самое:

Обозначения можно объединять, чтобы добраться до нужного коммита:

файл .gitignore — объясняем git, какие файлы следует игнорировать

Иногда по директориям проекта встречаются файлы, которые не хочется постоянно видеть в сводке git status. Например, вспомогательные файлы текстовых редакторов, временные файлы и прочий мусор.

Заставить git status игнорировать определенные файлы можно, создав в корне или глубже по дереву (если ограничения должны быть только в определенных директория) файл .gitignore. В этих файлах можно описывать шаблоны игнорируемых файлов определенного формата.

Пример содержимого такого файла:

Существуют и другие способы указания игнорируемых файлов, о которых можно узнать из справки git help gitignore.

Серверные команды репозитория

; git update-server-info : Команда создает вспомогательные файлы для dumb-сервера в $GIT_DIR/info и $GIT_OBJECT_DIRECTORY/info каталогах, чтобы помочь клиентам узнать, какие ссылки и пакеты есть на сервере.

; git count-objects : Проверка, сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория.
; git gc : Переупаковка локального репозитория.

Рецепты

Создание пустого репозитория на сервере

Импорт svn репозитория на Git-сервер

Ссылки

Compiling Linux Kernel 3.4.5 Vanilla Final — Debian way

Here is my guide on Compiling 3.4.x Vanilla Final — Ubuntu/Debian using the debian way

This article is about compiling a kernel on Ubuntu systems. It describes how to build a custom kernel using the latest unmodified kernel sources from www.kernel.org (vanilla kernel) so that you are independent from the kernels supplied by your distribution.
Install the Required packages for building it

Then download latest kernel version

support otherwise you will get this error

you can install the headers too from /usr/src/linux-headers-3.4.*-*
in my case i can show you how the packages are named

Детальные характеристики с помощью dmidecode

Просмотреть серийные номера железа и более детальные характеристики можно с помощью команды dmidecode:

Вот, пример вывода команды dmidecode с сервера IBM HS22:

 

Создание IPSec VPN туннеля между Linux и Cisco PIX

Создание IPSEC VPN туннеля на основе pre-shared keys между linux 2.6 ipsec-tools(racoon) и cisco PIX firewall 5xx

Введение:

Термин VPN (Virtual Private Network) переводится как «виртуальная частная сеть».

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

В моем примере будет создаваться защищенный IPSEC канал между двумя сетевыми устройствами, первое это Cisco PIX firewall — аппаратный фаервол от известного производителя и второе компьютер, работающий в качестве шлюза под управлением OS Linux. IPSEC стандарт разработанный и принятый к реализации, для повышения безопасности используемого IP протокола (см. http://www.rfc-editor.org/ RFC 2401 — IPSec) Ниже приводится небольшая схема поясняющая устанавливаемое соединение.

Схема соединения :

сети и интерфейсы :

сеть office_1 — 10.0.0.0/24
сеть office_2 — 192.168.0.0/24

pix_int — 10.0.0.1/24 (внутренний интерфейс, office_1)
pix_ext — 172.16.1.1 (внешний интерфейс)

linux_ext — 172.16.2.1 (внешний интерфейс)
linux_int — 192.168.0.1/24 (внутренний интерфейс, office_2)

Настраиваем pix (у меня был 506E):

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

Настройка Linux, на примере SLES-9 :

Использовалось стандартное ядро, поставляемое с SLES-9:

Опции ядра linux для пересборки, если у вас ядро не поддерживает IPSEC,
необходимые для поддержки IPSEC.

включить все пункты модулями

далее пересобираете ядро и перезагружаетесь в него.

Для установления соединения были использованы ipsec-tools-0.3.3-1.3 идущие в поставке SLES.

На момент написания статьи на сайте http://ipsec-tools.sf.net/ была доступна версия IPsec-tools 0.6.1

Настройка конфигурационных файлов /etc/racoon/ :

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

в файле setkey.conf определяются SA/SP базы (man setkey)

Содержимое:

конфигурационный файл для racoon — racoon.conf :

Далее запускаем racoon через /etc/rc.d/init.d/racoon start или руками

и при наличии трафика в тунеле, в логах вы увидите что-то похожее на :

для проверки, на linux сервере можете подать команду :

где xx IP из офисной сети 1, любой адрес (внутренний интерфейс pix’a пинговатся не будет)

Решение проблем:

просмотр текущего состояния тунеля на PIX’e осуществляется двумя командами:

 

При перезапуске или даже остановке racoon у вас возможно все-еще будет работать IPSEC VPN туннель так как используется реализация на уровне Linux ядра.

Для того чтобы перезапустить туннель на стороне PIX’a, необходимо выполнить 2 команды в _режиме конфигурации_ (conf t):

Как только появится трафик совпадающий по ipsec acl или при его наличии, туннель должен поднятся.

Starcraft 2 на Linux

Okie dokie — so I’ve mentioned before that I play Starcraft 2 under my Linux install with no issues. Since the game’s official release a few days ago I have been getting a good bit of traffic on those two pages — so I figured I would put together a quick HOWTO for getting Starcraft 2 working on your Linux distro of choice. The game runs under Wine 1.2 and/or Crossover Games 9.1 with a small bit of work (the latter is easier to make work).

Since free is good I’ll talk about the Wine HOWTO first. First off, download and install Wine 1.2 on your system. Next, run the following commands in terminal:

In the configuration Window it opens go to the libraries tab and enter mmdevapi in the new override for library box and click add. Now scroll through the existing over rides list for mmdevapi click edit and set it to disabled. Finally click on the audio tab and set it to alsa.

If you still have audio issues after doing this and your distro uses Pulse Audio (Ubuntu does) install Wine 1.2 that has been built with pulse audio support with the following commands in terminal:

As of Crossover 9.1 Starcraft 2 is listed as «officially support» and as such you will find that it has an entry in the automated games installer. The only issue is that after the game has actually finished installing the StarCraft 2 process hangs around — meaning Crossover never actually knows that the game has finished installing and thusly never creates menu entries for it. Thank fully there is a simple fix for this — after Starcraft 2 has finished installing, open up your system monitor and look for any rogue Starcraft 2 processes and kill them off. After you have done this the CXGames installer will know that it has finished installing and will create the menu entries as it should.

If you have audio issues under Crossover you can open your Starcraft 2 bottle’s WineCFG, select the audio tab, and set hardware acceleration from full to emulated.

Also — if you are trying to install from the retail CD (with Wine or Crossover) you might need need to manually mount the disc due to an issue with its split PC/Mac auto mounter. To do this run the following two commands in terminal:

Note some drives may use /dev/sr0 (or other mount points) instead if /dev/cdrom. If you are having issues getting it working scroll through the comments for some good tips — if you are still unable to get it working after that, make a comment of your own 🙂

Also — if you are attempting to get the game running with an ATI card, it was suggested in the comments that making it run under a virtual desktop allows it to run on some systems it otherwise fails to work on.

I tested the above methods on Ubuntu 10.04, Linux Mint Debian, and Chakra — but they should be applicable to any modern Linux distribution. Have any issues feel free to drop a comment below and I will do my best to lend a hand debugging. Happy gaming!

~Jeff Hoogland

Использование Cisco VPN Client на Linux

Стоит у меня несколько Cisco и прокинуты по ним туннели GRE между организациями, объединенные в свою сегментную сеть. Когда работал на форточках, проблем с подключением к сети не было. VPN клиент для Cisco под форточки работает прекрасно, но в связи с полным отказом от Windows возник вопрос запуска сие чуда на Debian. Как оказалось, стандартные средства организации vpn, входящие в состав репозитария системы, не обеспечивают решения данной задачи. Вот такую задачу мы и будем сегодня решать.

Поиски решения данной задачи в Гугле не привели к конкретному решению, поэтому все пришлось ставить путем проб и ошибок. Загруженные клиенты не хотели собираться в Debian. Спросите, почему нельзя получить клиента у поставщика, ответ: клиент может быть загружен только после регистрации и получения определенного статуса, вот так. Не у каждого есть возможность получить соответствующие права для загрузки. Поэтому принято решение получить все необходимое ПО из свободных источников. Предыстория понятна, пора начать все реализовывать. Все действия будем производить в консоли.

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

Как видите, здесь лежит только загруженный нами ранее vpn клиент Cisco. Необходимо установить исходники ядра, но перед установкой рекомендую обновить пакеты, дабы не наставить дырявого и устаревшего ПО.

Систему обновили, теперь посмотрим, что у нас есть по ядрам в пакетах.

Имеется новое ядро. Вот его и поставим. Напомню, что мы работаем со стабильной веткой Debian, если вы ставите эксперименты на боевой машине (сервере), подумайте хорошо —  сделайте копию. Ставим новое ядро и исходники к нему. Необходимые дополнительные библиотеки aptitude подхватит и установит сам. На всякий случай проверьте установлена ли утилита сборки проектов make. У меня ее почему-то не оказалось.

Проверяем содержимое …

Новое ядро установлено, исходные коды ядра тоже на месте, осталось только сделать рестарт системы и можно приступать к настройке и установке vpn клиента для Cisco.

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

Далее идут вопросы установщика и сборщика, отвечаем утвердительно.

Клиент собрался и установлена поддержка в ядро необходимых протоколов для работы VPN клиента Cisco. Далее необходимо создать конфигурацию и инициализировать клиента. Инициализация требуется один раз, если вы после этого перезапустите систему, то клиент инициализируется сам и при последующих запусках тоже. Если этого не происходит (как в моем случае), то можно произвести инициализацию вручную. Пока не стал разбираться, почему автомат не работает.

Теперь готовим файл конфигурации:

Если по каким-либо причинам профиль примера не создался, то вот его примерное содержимое:

Собствено редактирование профиля сводится к некоторым изменениям (чтоб их не вводить вручном режиме постоянно). Ниже выдержка, что необходимо поправить:

строки для правки:

Description=Краткое описание вашего профиля

Host=IP_адрес_вашей_Cisco

GroupName=Имя_вашей_группы_в_домене

Username=Ваше_имя_в_домене_NT

NTDomain=Имя_вашего_домена

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

Подключение успешно выполнено. Как видим туннель на удаленную сеть открыт и готов к транспорту пакетов. Отключение можно выполнить банальным сочетанием Ctrl+C или в другой консоли вводом команды разрыва соединения.

В другой консоли можно проверить ping любого адреса в удаленной сети. Можете запускать RDP, VNC или другую систему управления серверами или компьютерами. Адреса указывайте такие, как будто вы находитесь в домашней сети. Все это можно оформить аккуратней, но как всегда лень. Зато у вас будет желание сделать все красивее и качественней. Удачи с экспериментами.

http://www.qdesnic.ru/page/cisco_vpnclient.html