Sed mans

Команда s - substitution (замена)

sed s/ОБРАЗЕЦ/ЗАМЕНА/

Sed использует в качестве разделитея первый символ после s (кроме обратного слеша \ и символа новой строки):

sed -i "s/строка/новая строка/g" file
тоже самое
sed -i "s#строка#новая строка#g" file

-i заставляет sed делать замену в исходном файле без вывода на экран.

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

\xabc\xdefx

выведет abcxdef

По умолчанию команда s заменяет только первое совпадение, чтобы заменить все найденные совпадения используется модификатор /g

$ echo кот этот, был самый обычный кот | sed 's/кот/котенок/g'

котенок этот, был самый обычный котенок

Опция -n отменяет вывод на стандартный выход.  
Модификатор /p - Если замена имела место, то вывести результат.

Вывести только те строки, где произошла замена.

sed -n 's/gnome/penguin/p' file

Использование символа & когда искомый ОБРАЗЕЦ неизвестен

Символ & (амперсанд), будучи помещен в состав ЗАМЕНЫ, означает любой найденный в тексте ОБРАЗЕЦ.
"& " - Заменяется на строку, указанную в регулярном выражении. 
Например:

$ echo 1234 | sed 's/[0-9]*/(&)/'
(1234)

Числовой модификатор

Это число от 1 до 512, которое ставится после последнего разделителя и указывает, какое по счету совпадение подлежит замене.

$ echo очень глупый пингвин | sed 's/[а-я]*/хороший/2'
очень хороший пингвин

Можно комбинировать цифровой модификатор с модификатором /g. Если нужно оставить неизменным первое слово, а второе и последующие заменить на слово "(удалено)", то команда будет такая:

$ echo очень глупый пингвин | sed 's/[а-я]*/(удалено)/2g'
очень (удалено) (удалено)

Модификатор d

Удаляет строки по регулярному выражению

sed '/pattern/d'

Команда ! (отрицание)

Символ восклицательного знака (!) инвертирует выбор
Замена "foo" на "bar" ИСКЛЮЧАЯ строки содержащие "baz":

sed '/baz/!s/foo/bar/g'

Удалим все строки кроме второй.

$ sed '2 !d' text.txt

Замена "foo" на "bar" ТОЛЬКО для строк содержащих "baz": Заменить все совпадения в файле twpol.txt с аргументами из файла grlog4 на префикс # плюс аргумент

cat grlog4 | while read i; do sed -i -e "s&$i&#$i&g" twpol.txt;done

Кавычки в Unix

Кавычки, обрамляющие строку, предотвращают интерпретацию специальных символов, которые могут находиться в строке.
Символ называется "специальным", если он не только означает самого себя но и имеет дополнительное значение для программ, например символ шаблона -- *.

Двойные кавычки отменяют все спец символы, кроме $ и \.

Одиночные кавычки (' '), по своему действию схожи с двойными кавычками, но не разрешают внутри себя подстановку переменных, интерпретируя символ "$", как обычный символ. Любой символ внутри одинарных кавычек, за исключением символа одинарной кавычки, воспринимается как обычный символ.
Одинарные кавычки являются более строгим вариантом двойных кавычек.

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

grep '[Tt]*' ./[Bb]*

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

var="is a variable"

echo this $var # здесь команде передается  4 аргумента

echo "this $var"  # а тут один

this is a variable # здесь на выходе мы получаем 4 слова
this is a variable # а здесь одну строку

При обращении к переменным, желательно использовать двойные кавычки. Это позволит не интерпретировать специальные символы, содержащиеся в именах переменных, за исключением символов $

# ls /etc\ /root

вернет /etc/root

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

# ls /etc\\n/root

вернет /etc/root

Вообще если одна из строк многострочной команды заканчивается символом конвейера " | ", экранировать символ новой строки не обязательно, это просто считается хорошим тоном, и применимо только к оболочке bash

sysctl

sysctl используется для изменения параметров ядра во время выполнения. Доступные параметры перечислены в /proc/sys/. Для поддержки sysctl(8) в Linux необходима поддержка файловой системы procfs. sysctl может использоваться как для чтения, так и для записи параметров ядра. 

-n
    Не выводить имена ключей при выводе их значений. 
-e
    Игнорировать ошибки, связанные с неизвестными ключами. 
-N
    Выводить только имена. Это может быть полезно для оболочек, поддерживающих настраиваемое автодополнение. 
-q
    Не выводить устанавливаемые значения на стандартный вывод. 
-v
    Выводить устанавливаемые значения на стандартный вывод. 
-w
    Этот параметр используется для изменения значений ключей. 
-p
    Загрузить настройки из указанного файла или /etc/sysctl.conf, если файл не указан. 
-a
    Вывести все доступные в данный момент настройки. 
-A
    Вывести все доступные в данный момент настройки в табличном виде. 

Примеры:

/sbin/sysctl -a
/sbin/sysctl -n kernel.hostname
/sbin/sysctl -w kernel.domainname="example.com"
/sbin/sysctl -p /etc/sysctl.conf 

Перед добавлением правил следует удостовериться, поддерживает ли их sysctl на вашей системе.

sysctl -a | grep ...

Чистим логи в Linux

Первое что нам необходимо сделать после получения рут привилегий это:

Отключить сохранение команд текущей сессии в истории Bash:

unset HISTFILE

или

export HISTFILE=/dev/null

export MYSQL_HISTFILE=/dev/null 

freebsd
setenv histfile /dev/null
setenv MYSQL_HISTFILE /dev/null

Далее после работы, нам нужно очистить логи с записями о нашем присутствии в системе. Сделать это можно двумя способами:
1. С помощью специальных утилит (Log Wiper,Log Cleaner, etc)
2. В ручную

Не помешает также подчистить .bash_history, в котором сохраняется история команд.

Далее перед отключением делаем:

kill -9 $$

kill -9 $$ - это выход из консоли без без сохранения истории, где $$ идентификатор текущего процесса консоли.

Если вы решили довериться утилитам, то можно воспользоваться одной из этих утилит:
http://packetstormsecurity.com/UNIX/penetration/log-wipers/
Наиболее популярные: vanish , whitecat

Рассмотрим whitecat. Она поддерживает FreeBSD, Linux, SOLARIS.
Последняя версия 1.1: http://forum.antichat.ru/threadnav36595-4-10.html
Пути к логам находятся в массиве APACHE_PATH[] (стр. 54, файл witecat.c). Чтобы добавить новый путь - просто добавьте строчку в массив, соблюдая запятые. Во время работы при попытке обработать несуществующий путь ошибки не вываливаются.  

Компиляция: gcc whitecat.c -o whitecat

Запуск(например хотим почистить свой ip в логах):

./whitecat -u root -a 127.0.0.1

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

egrep -rl "127.0.0.1" /var | while read f; do sed -e '/127.0.0.1/d' $f>1.back;touch -r $f time.tmp;mv -f 1.back $f;touch -r time.tmp $f;rm -f time.tmp;done

Если остаются пустые строчки - их тоже можно удалить:

sed '/^$/d' new

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

Описание системы ведения логов

В Unix программы могут вести свои собственные логи или использовать для этого демон syslogd. С помощью этого демона любые другие демоны или службы могут заносить в общие логи (файлы журналов) свою информацию. Таким образом для всех программ можно установить единый метод регистрации событий, за что и отвечает syslogd. Итак сислог-демон распределяет события по категориям и важности (приоритетам), а также в зависимости от конфигурации решает куда отправить запись о данном событии. Все настройки, отвечающие за это, хранятся в файле /etc/syslog.conf. Посмотрим на пример конфигурационного файла syslog'a, который мы взяли из Red Hat linux 9.0 установленного с дефолтными параметрами:

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages

# The authpriv file has restricted access.
authpriv.* /var/log/secure

# Log all the mail messages in one place.
mail.* /var/log/maillog


# Log cron stuff
cron.* /var/log/cron

# Everybody gets emergency messages
*.emerg *

# Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler

# Save boot messages also to boot.log
local7.* /var/log/boot.log

Слева пишется категория и привилегия события, а справа - файл куда это событие заносится:
катeгория.приоритет адрес_лог_файла
Звездочка, как можно легко догадаться, означает все категории или все приоритеты. Теперь немного поподробнее о категориях:

auth - сообщения о нарушении авторизации доступа;
authpriv - сообщения о привилегированном доступе;
cron - сообщения демона крон;
daemon - сообщения других демонов;
kern - сообщения ядра;
lpr - сообщения системы печати;
mail - сообщения почтовых программ;
news - сообщения новостных программ;
syslog - сообщения самого демона сислог;
security - тоже самое что и auth (не должно использоваться в новых системах);
user - сообщения программ юзеров;
uucp - сообщения UUCP;
local0-local7 - определяется для конкретной системы.

Почти понятно? Тогда рассмотрим уровни приоритетов:
emerg - системе амбец;
alert - нужно срочное вмешательство;
crit - состояние критично и представляет угрозу работе системы;
err - сообщение об ошибках;
warnity - предупреждение;
notice - состояние допустимое, но админ должен это увидеть;
info - просто информация;
debug - отладочные сообщения;
none - нет приоритета.
Таким образом, настройки файла /etc/syslog.conf определят заносить ли какое-либо конкретное сообщение в файл журнала или нет.

 Теперь посмотрим куда могут отправляться сообщения.
/путь/имя_файла - сообщения записываются в лог-файл;
/dev/console (что в нашем примере) - сообщение передается на терминал (т.е. их можно увидеть на мониторе, подключенном к данной машине);
root,user1,user2 - имена пользователей, на терминал которых будет выводиться сообщение;
* - сообщения выводятся на терминалы всех пользователй (см. пример с *.emerg);

mail.=info                   /dev/tty12

| - знак конвеера означает, что сообщение передается другой программе (например | "mail root" - сообщение передается руту по почте);
@имя_хоста - сообщения отправляются на удаленный компьютер (демону syslogd).
Последнее и есть самая опасная вещь - логи удастся почистить только если взломать второй хост.

*.*             @megalohost

Рекомендуется также заглянуть в файл /var/log/messages, где могут сохраниться системные сообщения от применения эксплойтов или других действий.

  /var/log/lastlog
lastlog — содержит записи о времени последнего входа в систему для каждого пользователя. Этот файл содержит только одну запись для каждого пользователя.

/var/log/wtmp/
wtmp — содержит записи обо всех входах в систему (и выходах из системы) по пользователям. На загруженном компьютере этот файл имеет большой размер, поскольку содержит по одной записи входа и одной – выхода из системы. Файл также содержит дополнительную системную информацию, такую как перезагрузка, выключение и изменение даты.

/var/run/utmp 
Файл utmp позволяет получать информацию о том, кто в данный момент работает в системе. Пользователей, в данное время использующих систему, может быть большое количество, поскольку не все программы используют регистрацию через utmp.

Файл /var/log/btmp записывает неправильные регистрации. 

При входе пользователя в систему открывается файл lastlog, и в нем обновляется запись о дате и времени входа. Затем открывается файл utmp, и в него записывается информация о текущем нахождении в системе. Запись о входе в систему (как правило, копия информации, добавленной в lastlog) записывается также в журнал wtmp для регистрации входа в систему.
При выходе пользователя из системы запись о нахождении в системе, внесенная в utmp, удаляется (с этого момента пользователь не зарегистрирован в системе), а в wtmp вносится дополнительная запись для регистрации того, что пользователь вышел из системы. 

Мы можем отредактировать wtmp файл вручную с помощью утилиты fwtmp.

Преобразуем двоичный файл wtmp в текстовый файл:

fwtmp < wtmp.mmdd > wtmp.new

Команда fwtmp преобразует wtmp из двоичного кода в текстовый формат.
Отредактируйте текстовый файл wtmp.new, удалив/отредактировав нужные записи
Преобразуем текстовый файл wtmp.new обратно в двоичный формат:

fwtmp -ic < wtmp.new > wtmp.mmdd

Если файл wtmp восстановить невозможно, то с помощью команды nulladm создайте пустой файл wtmp:

nulladm wtmp

Утилита wtmpfix поможет скорректировать согласованность системной даты и времени в файле wtmp, если в нем появились ошибки.

http://xaknotdie.org/defaced/3/d3_09.html 

Правильная очистка файлов с логами

> cp /var/log/messages /var/log/messages.old
> echo "" > /var/log/messages

Это абсолютно не правильно. Здесь есть риск потери информации, в то время как при таком раскладе:

mv /var/log/messages /var/log/messages.old
cat /dev/null > /var/log/messages
kill -HUP $syslog_pid

нет риска потери информации.

Все дело в том, что после команды mv запись продолжается в переименованный файл и только после SIGHUP демон переключается на новый.

Emma Hewitt - Colours (Armin Van Buuren mix ) Brakedown

Порядок выполнения деректив mod_rewrite

1. RewriteRule
2. RewriteCond (хоть он и идет первым в конфигах, но выполняется после RewriteRul)
3. RewriteBase (в конце обработки RewriteBase дописывает к результату указанный путь)

При составлении более-менее сложных конфигураций mod_rewrite важно понимать, что изменение запроса не заканчивается на последнем RewriteRule. После того, как сработало последнее правило RewriteRule и был добавлен RewriteBase, mod_rewrite смотрит, изменился запрос или нет. Если запрос изменился, его обработка начинается заново с начала файла .htaccess.

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

— Постойте, но ведь есть флаг [L], который останавливает обработку запроса mod_rewrite'ом!

Не совсем так. Флаг [L] останавливает текущую итерацию обработки запроса. Однако если запрос был изменен теми RewriteRule, которые все-таки успели отработать, Apache запустит цикл обработки запроса заново с первого RewriteRule.

http://habrahabr.ru/company/sprinthost/blog/129560/

htaccess 6 - RewriteBase

После того как все преобразования произведены и выполнено последнее RewriteRule, вступает в силу RewriteBase.

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

    images/logo.gif — относительный.

    /images/logo.gif — абсолютный (в начале слеш).

    http://example.com/images/logo.gif — самый абсолютный из всех.

Что будет, если не указать RewriteBase? По умолчанию Apache делает его равным абсолютному пути на файловой системе до .htaccess (например, /var/www/example.com/templates/).

htaccess 5 - RewriteMap

Директива RewriteMap - ассоциативный массив преобразований, который может быть использован в правилах преобразований.
http://httpd.apache.org/docs/current/rewrite/rewritemap.html

Краткий справочник svn (subversion)

svn checkout http://repository.url/svn/name — извлекаем файлы проекта из репозитория, сокращение: svn co;
svn update — получаем обновления из репозитория, сокращение: svn up;
svn update -r rev_num ./file_name — извлекаем ревизию файла с номером rev_num;
svn add ./file_name — добавляем файл в репозиторий (не важно текстовый или бинарный);
svn commit ./file_name — заливаем файл в репозиторий (не важно текстовый или бинарный);
svn rename ./old_file_name ./new_file_name — переименовываем файл в репозитории;
svn remove ./file_name — удаляем файл/директорию из репозитория;
svn status — просматриваем локально измененные файлы, сокращение: svn st;
svn status -u — просматриваем локально измененные и изменившиеся в репозитории файлы, сокращение: svn st -u;
svn diff ./file_name — показывает локальные изменения в файле построчно;
svn diff -r rev_num1:rev_num2 ./file_name — показывает различия между ревизией rev_num1 и rev_num2 файла;
svn revert ./file_name — откатывает локальные изменения файла (выгружает из репозитория последнюю закоммиченную ревизию);
svn revert -R ./ — откатывает все локальные изменения файлов;
svn log ./file_name — список ревизий с комментариями;
svn blame ./file_name — показывает авторов изменений файла построчно, синоним: svn annotate;
svn propset svn:ignore ./file_name . — добавляем файл в список игнорируемых файлов;
svn propset svn:keywords "Id Author Date" ./file_name — установка атрибутов файла;
svn cleanup — снимает блокировки с файлов;
svn unlock http://repository.url/svn/file_name — снять блокировку файла (URL можно узнать с помощью команды svn info ./file_name | grep URL, его и нужно передавать в svn unlock);
svnadmin setlog --bypass-hooks /path/to/repository -r rev_num ./commit_text_file — заменяет текстовое описание коммита, где rev_num — номер ревизии, commit_text_file — путь к файлу, содержащему новый комментарий к коммиту;
svn help command_name — выводит помощь по команде command_name, например, «svn help update»;
svn merge -r rev_to_rollback:rev_good ./file_name — откатываем ревизию номер rev_to_rollback до ревизии rev_good, причем все изменения старше rev_to_rollback сохраняются (Например, у файла есть ревизии 11,12 и 13. Хотим откатить 12-ую ревизию, но так, что бы изменения 13-ой остались в силе. Делаем тогда так: svn merge -r 12:11 ./file_name);
svn copy http://repository.url/svn/name/trunk/ http://repository.url/svn/name/branches/new_branch_name/ — создаем ветку с названием new_branch_name из главной линии разработки;
svn merge --dry-run -r rev_num1:rev_num2 http://repository.url/svn/name/trunk/ — проверяем, что будет изменено при объединении веток, где rev_num1 — номер ревизии, когда ваша ветка была «открыта», или это м.б. номер предыдущего объединения (слияния), rev_num2 — версия главной линии разработки, с которой производим объединение. Необходимо отметить, что все изменения будут применены для директории, в которой выполнялась эта команда;
svn merge -r rev_num1:rev_num2 http://repository.url/svn/name/trunk/ — синхронизирует вашу ветку с главной линией разработки с учетом ревизий: rev_num1 — номер ревизии, когда ваша ветка была «открыта», или это м.б. номер предыдущего объединения (слияния), rev_num2 — версия главной линии разработки, с которой производим объединение. Необходимо отметить, что все изменения будут применены для директории, в которой выполнялась эта команда;