Поиск файла по его временным атрибутам

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

Например

  • Найти все папки измененные с конца обеда вчерашнего дня
$> find . -newerct 'yesterday 14:00' -and -type d -print
  • Найти и удалить все файлы старше двух недель
$> find . -not -newerBt '2 week ago' -and -type f -unlink
  • Нужно найти все файлы, которые были созданы с трех часов ночи позавчерашнего до обеда вчерашнего дня
$> find . -newerBt '2 day ago 03:00' -and -not -newerBt 'yesterday 13:00' -and -type f -print

Список ключей, ответственных за фильтрацию по временным атрибутам

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

-Bnewer file
Смотрите описание -newerBm.

-Btime n[smhdw]
Если не определены никакие единицы времени, этот ключ вычисляется как истина если разница между временем создания файла и временем начала поиска, округленная до 24-часового периода в большую сторону, составляет n 24-часовых периодов.
Если определены единицы времени, этот ключ вычисляется как истина если разница между временем последнего изменения информации о файле и временем начала поиска составляет n единиц времени. Пожалуйста обратитесь к описанию ключа -atime для получения информации о поддерживаемых единицах времени.

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

-anewer file
Смотрите описание -neweram.

-atime n[smhdw]
Если не определены никакие единицы времени, этот ключ вычисляется как истина если разница между временем последнего доступа к файлу и временем начала поиска, округленная до 24-часового периода в большую сторону, составляет n 24-часовых периодов.
Если определены единицы времени, этот ключ вычисляется как истина если разница между временем последнего доступа к файлу и временем начала поиска составляет точно n единиц времени. Возможные единицы времени:

  • s секунда
  • m минута (60 секунд)
  • h час (60 минут)
  • d день (24 часов)
  • w неделя (7 дней)

В аргументе ключа единицы времени можно комбинировать в произвольном порядке. Для примера «-atime -1h30m». Единицы времени используются только совместно с модификаторами «+» или «-».

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

-cnewer file
Смотрите описание -newercm.

-ctime n[smhdw]
Если не определены никакие единицы времени, этот ключ вычисляется как истина если разница между временем последнего изменения информации о файле и временем начала поиска, округленная до 24-часового периода в большую сторону, составляет n 24-часовых периодов.
Если определены единицы времени, этот ключ вычисляется как истина если разница между временем последнего изменения информации о файле и временем начала поиска составляет n единиц времени. Пожалуйста обратитесь к описанию ключа -atime для получения информации о поддерживаемых единицах времени.

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

-mtime n[smhdw]
Если не определены никакие единицы времени, этот ключ вычисляется как истина если разница между временем последнего изменения файла и временем начала поиска, округленная до 24-часового периода в большую сторону, составляет n 24-часовых периодов.
Если определены единицы времени, этот ключ вычисляется как истина если разница между временем последнего изменения файла и временем начала поиска составляет n единиц времени. Пожалуйста обратитесь к описанию ключа -atime для получения информации о поддерживаемых единицах времени.

-newer file
-mnewer file

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

-newerXY file
Истина если у текущего файла более позднее время доступа (X=a), время создания (X=B) или время изменения (X=m) чем время доступа (Y=a), время создания (Y=B) или время изменения (Y=m) указанного файла (file). В дополнение, если Y=t то file трактуется как время, заданное в одном из описанных в cvs(1) форматов. Отметьте, что -newermm эквивалентен -newer.

Выдержка из man для cvs(1)
Поддерживается множество вариантов форматов для описания даты, в частности ISO и Интернет. В случае, если временная зона в дате не указана явным образом, она трактуется в местной временной зоне. Примеры допустимых форматов:

  • 1 month ago
  • 2 hours ago
  • 400000 seconds ago
  • last year
  • last Monday
  • yesterday
  • a fortnight ago
  • 3/31/92 10:00:07 PST
  • January 23, 1987 10:05pm
  • 22:00 GMT

Настройка синхронизации времени на сервере FreeBSD

Прописываем в /etc/rc.conf

    ntpdate_enable="YES"
    ntpd_enable="YES"

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

Далее в /etc/ntp.conf пишем (рекомендуемые сервера с ntp.org)

    server 0.pool.ntp.org
    server 1.pool.ntp.org
    server 2.pool.ntp.org
    restrict 127.0.0.1

Строка restrict 127.0.0.1 разрешает управление демоном ntpd только с localhost (например для работы утилиты ntpd), можно вообще закрыть доступ написав restrict default ignore или разрешить только из локальной сети restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap — разрешит синхронизацию времени, но запретит настраивать сервер или быть равноправными участниками синхронизации времени.

И собственное все, подводим часы

    # /etc/rc.d/ntpdate start
    Setting date via ntp.
    23 Jan 00:56:48 ntpdate[928]: step time server 193.125.143.140 offset 0.027002 sec

и запускаем демон

    # /etc/rc.d/ntpd start
    Starting ntpd.

Смотрим что ntpd запустился нормально

    # ps ax|grep ntpd
    1044 ?? Ss 0:00,04 /usr/sbin/ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift
    # tail /var/log/messages
    Jan 23 00:57:09 lola ntpd[1043]: ntpd 4.2.4p5-a Mon Jan 5 16:59:33 IRKT 2009 (1)
    # ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
     petrel.telecom. 192.36.143.150   2 u   60   64    1  119.017  5082.52   0.004
     hornet.itconnec 89.111.168.177   4 u   59   64    1  134.423  5086.05   0.004
     jane.telecom.mi 192.36.143.151   2 u   58   64    1  120.222  5086.08   0.004

Источник

Преобразование ссылок с помощью Apache (mod_rewrite)

Допустим, у вас есть работающий веб-сайт, состоящий из большого количества статических html-страниц. Все идет хорошо, но вдруг в какой-то момент вы решаете усовершенствовать работу веб-сайта и добавляете динамические скрипты: в результате страничка новостей теперь доступна по ссылке http://www.site.com/cgi-bin/news.cgi вместо прежней http://www.site.com/news.html, а каталог, в котором хранились страницы с описанием российских регионов, полностью перекочевал в динамику, и наш горячо любимый 77-й регион теперь доступен по неэстетично выглядящей ссылке http://site.ru/cgi-bin/regions.pl?region=77&mode=brief вместо легко запоминаемой http://site.ru/regions/77.html.

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

Анализ проблемы наводит на мысль о том, как хорошо было бы иметь возможность обращаться к одним и тем же страницам по различным HTTP-ссылкам, причем для страниц с похожими ссылками было бы очень удобно описать одно общее для них правило вместо того, чтобы для каждой страницы выписывать все возможные варианты ведущих на нее HTTP-ссылок. Если ваш веб-сайт работает под управлением весьма популярного в настоящее время веб-сервера Apache (скорее всего, это именно так), то в вашем распоряжении есть мощнейшее средство преобразования ссылок, которое реализуется специальным программным модулем mod_rewrite. Некоторые директивы данного модуля могут использоваться только в конфигурационном файле самого веб-сервера, другие же — в специальных файлах .htaccess, которые можно располагать в подкаталогах иерархии вашего веб-сайта. Именно эти директивы из .htaccess и производят основную работу по преобразованию ссылок, поэтому их мы опишем более подробно.

Для перестраховки можно уточнить у службы технической поддержки вашего хостера, включен ли модуль mod_rewrite в состав веб-сервера, обслуживающего ваш веб-сайт, и допускается ли использование его директив в файлах .htaccess. Поскольку данный модуль широко используется во многих проектах, каждый уважающий себя хостер на оба ваших вопроса ответит: «Да, конечно». Если же вы получили отрицательный ответ, это хороший повод задуматься о смене хостинг-провайдера на другого, предоставляющего более качественные услуги.

Прежде чем углубиться в описание возможностей модуля mod_rewrite, приведем пример решения двух описанных выше проблем:

# Включение преобразования ссылок
RewriteEngine on
# Новостная страница
RewriteRule ^news.html$ /cgi-bin/news.cgi
# Страницы с описаниями регионов
RewriteRule ^regions/([0-9]+)\.html$ /cgi-bin/regions.pl?region=$1&mode=brief

Директива RewriteEngine включает или выключает преобразование ссылок (соответственно «RewriteEngine on» или «RewriteEngine off»). Действие директивы распространяется на текущий каталог и на все его подкаталоги, в которых нет своих файлов .htaccess с данной директивой.

Правила преобразования ссылок наследуются чуть сложнее. Чаще всего преобразование по умолчанию отключено в основном конфигурационном файле веб-сервера. Допустим, что вы записали в .htaccess некоего каталога директиву «RewriteEngine on» и некоторое количество правил преобразования. Перейдем теперь в один из подкаталогов. Если здесь нет файла .htaccess, либо в нем нет ни одной директивы модуля mod_rewrite, то все правила преобразования наследуются от родительского каталога. Если в файле .htaccess есть хотя бы одна директива модуля mod_rewrite, то не наследуется ничего, а состояние по умолчанию выставляется таким же, как в главном конфигурационном файле веб-сервера (по умолчанию «off»). Поэтому, если вы желаете иметь в этом каталоге свой набор правил преобразования, не забудьте добавить директиву «RewriteEngine on». Есть и третий вариант. Допустим, вы желаете унаследовать все правила из родительского каталога и добавить к ним несколько новых — для этого вам понадобится директива RewriteOptions, которая допускает только один фиксированный аргумент. Таким образом, в файл .htaccess вы должны записать ваши новые правила и две директивы: «RewriteEngine on» и «RewriteOptions inherit».

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

RewriteRule «исходный путь» «замена» «флаги»

Исходный путь — это часть исходной ссылки, от которой отрезаны имя сервера, путь до текущего каталога и параметры запроса. Допустим, что ваш веб-сайт www.site.com расположен в каталоге /home/site/www. Тогда для ссылки http://www.site.com/test/list.html?mode=0 исходным путем в каталоге /home/site/www будет test/list.html, а в каталоге /home/site/www/test — list.html. Исходный путь задается регулярным выражением. Символ ! перед исходным путем означает, что правило «срабатывает» по несовпадению ссылки с заданным регулярным выражением.

Замена — это то, на что будет заменена исходная ссылка в случае «срабатывания» правила. Замена может быть относительной (если она не начинается с символа /) и абсолютной (если она начинается с символа / или представляет собой полную ссылку, начинающуюся с http:// или https://). В замене можно использовать определенные части исходного пути, отмеченные круглыми скобками. При этом макрос $1 обозначает ту часть исходного пути, которая расположена внутри первой пары скобок, $2 — внутри второй пары и так далее.

Флаги — это дополнительные опции для данного правила, которые перечисляются в квадратных скобках через запятую.

  • R (redirect) останавливает процесс преобразования и возвращает результат браузеру клиента как редирект на данную страницу (302, MOVED TEMPORARY). С данным флагом можно указать другой код результата, например «R=301» возвратит редирект с кодом 301 (MOVED PERMANENTLY).
  • F (forbidden) возвращает ошибку 403 (FORBIDDEN).
  • G (gone) возвращает ошибку 410 (GONE).
  • P (proxy) — по этому флагу Apache выполняет подзапрос (sub-request) к указанной странице с использованием программного модуля mod_proxy, при этом пользователь ничего не узнает об этом подзапросе. Если модуль mod_proxy не входит в состав вашей сборки Apache, то применение данного флага вызовет ошибку.
  • L (last) останавливает процесс преобразования, и текущая ссылка считается окончательной.
  • N (next) запускает процесс преобразования с первого по порядку правила.
  • C (chain) объединяет несколько правил в цепочку. Если первое правило цепочки «не срабатывает», то вся цепочка игнорируется.
  • NS (nosubreq) разрешает «срабатывание» правила только для настоящих запросов, игнорируя подзапросы (подзапрос может быть вызван, например, включением файла при помощи директивы SSI).
  • NC (nocase) отключает проверку регистра символов.
  • QSA (qsappend) добавляет исходные параметры запроса (query string) к замене. Если замена не включает в себя новые параметры запроса, то исходные параметры запроса добавляются автоматически. Если же включает, то без флага QSA исходные параметры запроса будут утеряны.
  • PT (passthrough) останавливает процесс преобразования и передает полученную новую ссылку дальше «по цепочке», чтобы над ней могли «поработать» директивы Alias, ScriptAlias, Redirect и им подобные (тогда как при флаге L новая ссылка считается окончательной и не подлежит дальнейшей обработке).
  • S (skip) пропускает следующее правило, если данное правило «сработало». Можно пропускать несколько правил, если указать их количество, например: «S=3».
  • E (env) устанавливает переменную окружения, например: «E=переменная:значение».

Примеры (во всех случаях показано содержимое файла .htaccess, расположенного в корневом каталоге веб-сайта):

# Пример 1. Каталоги проектов project1 и project2 веб-сайта www.site.com ранее содержали статические 
# html-страницы, теперь же эти страницы расположены на двух отдельных веб-сайтах project1.ru и project2.ru 
# (в той же иерархии)
 
# Первый способ требует наличия модуля mod_proxy и создает дополнительную нагрузку на веб-сервер, но зато 
# посетитель веб-сайта не знает, откуда в действительности выбираются веб-страницы
 
# Символы / даются с вопросительными знаками, чтобы правильно обработать ссылки вида
# http://www.site.com/project1 и http://www.site.com/project1/
 
RewriteRule ^project1/?(.*) http://project1.ru/$1 [P]
RewriteRule ^project2/?(.*) http://project2.ru/$1 [P]
 
# Второй способ возвращает внешние редиректы, так что посетитель увидит в адресной строке своего браузера, 
# что страницы реально расположены на других веб-сайтах
 
RewriteRule ^project1/?(.*) http://project1.ru/$1 [R]
RewriteRule ^project2/?(.*) http://project2.ru/$1 [R]
 
# Допустим, что в редиректах мы желаем передать в запросе какие-нибудь дополнительные параметры. 
# Применение флага QSA позволит нам сохранить параметры оригинального запроса, так что ссылка 
# http://site.com/project1/news.pl?mode=daily будет преобразована в
# http://project1.ru/news.pl?came_from=site.comamode=daily
 
RewriteRule ^project1/?(.*) http://project1.ru/$1?came_from=site.com [R,QSA]
RewriteRule ^project2/?(.*) http://project2.ru/$1?came_from=site.com [R,QSA]
# Пример 2. Электронная книга отдается динамическим скриптом в то время как нам желательно иметь 
# "красивую" иерархию вида "http://lib.ru/book1/chapter3.html". Кстати, расширение .html помогает нам скрывать 
# динамическую природу нашего веб-сайта
 
RewriteRule ^([a-z0-9]+)/([a-z0-9]+)\.html$ /cgi-bin/view_chapter.cgi?book=$1&chapter=$2 [NC]
# Пример 3. Нам желательно скрыть от пользователя используемую на веб-сайте технологию, для чего мы не будем 
# пользоваться расширениями в наших http-ссылках. Без флага L данное правило зациклится
 
RewriteRule (.+) $1.html [L]
 
# В то же время посетитель может ввести ссылку с расширением по одному ему понятным причинам. Правильно 
# обработать такую ситуацию поможет следующее правило:
 
RewriteRule ^([^.]+) $1.html [L]
# Пример 4. На веб-сайте есть статические ссылки с расширением .html и динамические ссылки с расширением .pl. 
Допустим, что динамические ссылки остались прежними, а статические должны обрабатываться cgi-скриптом
# Первый вариант предельно прост:
 
RewriteRule (.+)\.html$ /cgi-bin/new_script.cgi?page=$1 [L]
 
# Второй вариант более общий. Например, если нам нужно преобразовать массу различных ссылок кроме одной-двух, 
# можно воспользоваться специальной "заменой без изменения" (обозначается символом -):
 
RewriteRule \.pl$ - [L]
RewriteRule (.*) /cgi-bin/new_script.cgi?page=$1 [L]
# Пример 5. Есть один особый случай, когда делается внешний редирект на относительную ссылку. Допустим, мы 
# находимся в каталоге /home/site.com/www/test веб-сайта site.com. Каталог доступен по ссылке http://site.com/test/. 
# Нам нужен внешний редирект с файлов *.html на *.shtml. Приводимые директивы записываются 
# в файл /home/site.com/www/test/.htaccess
 
# Решение тривиально, если использовать абсолютную замену, но в этом случае нам приходится жестко прописывать 
# название каталога, что не совсем хорошо:
 
RewriteRule (.+)\.html /test/$1.shtml [R]
 
# Если написать замену как относительную ссылку (см. ниже), то результат будет не таким, каким мы его ожидаем 
# увидеть (это обусловлено особенностями преобразования ссылок на уровне каталогов): например, ссылка 
# http://site.com/test/aaa.html будет преобразована в http://site.com/home/site.com/www/test/aaa.shtml
 
RewriteRule (.+)\.html $1.shtml [R]
 
# По полученной ссылке видно, что там подставлен полный реальный путь к нужному файлу. Решить проблему можно 
# при помощи директивы RewriteBase, параметром которой является префикс для всех относительных замен, 
# находящихся в данном файле .htaccess
 
RewriteBase /test
# Пример 6. Задание переменных окружения применяется очень редко, но тем не менее приведем два примера, 
# не нуждающихся в пояснении
 
# Сохраняет в окружении расширение исходного файла
 
RewriteRule ^([^.]+)\.([a-z]+)$ /cgi-bin/new_script.cgi?page=$1 [L,E=EXT:$2]
 
# Сохраняет в окружении содержимое http-заголовка X-Forwarded-For
 
RewriteRule \.(cgi|pl)$ - [L,E=%{HTTP:X-Forwarded-For}]

Несмотря на такое изобилие, преобразование ссылок не ограничивается только директивой RewriteRule. Есть еще одна директива, которая используется не менее часто — это директива RewriteCond. Данная директива предназначена для проверки некоторых дополнительных параметров и всегда ставится непосредственно перед директивой RewriteRule. Если директива RewriteCond «срабатывает», то проверяется следующая за ней директива RewriteRule, если же «не срабатывает», то директива RewriteRule игнорируется.

# Если подряд записаны несколько директив RewriteCond, то следующая за ними директива RewriteRule 
# проверяется только в том случае, когда "сработали" все директивы RewriteCond:
 
RewriteCond условие1
RewriteCond условие2
RewriteRule преобразование1
RewriteRule преобразование2
 
# Следует обратить внимание, что в приведенном выше примере вторая директива RewriteRule проверяется в любом 
# случае, так как все директивы RewriteCond относятся только к первой директиве RewriteRule. Если же вы желаете, 
# чтобы условия относились к обеим директивам RewriteRule, то вам придется повторить их еще раз:
 
RewriteCond условие1
RewriteCond условие2
RewriteRule преобразование1
RewriteCond условие1
RewriteCond условие2
RewriteRule преобразование2
 
# Применение флага OR позволяет объединять условия не по И (как это делается по умолчанию), а по ИЛИ. В 
# следующем примере директива RewriteRule проверяется, если выполняется любое из двух предшествующих условий:
 
RewriteCond условие1 [OR]
RewriteCond условие2
RewriteRule преобразование
 
Синтаксис директивы RewriteCond выглядит следующим образом:
 
RewriteCond «проверяемое выражение» «условие» «флаги»

Проверяемое выражение — это строка, которая может состоять из обычных символов, макросов и переменных. Макросы $1, $2 и так далее ссылаются на соответствующие выражения в скобках из следующей по порядку директивы RewriteRule. Макросы %1, %2 и так далее ссылаются на выражения в скобках из предыдущей по порядку директивы RewriteCond. Кстати, макросы %* могут также использоваться и в директивах RewriteRule для ссылки на предыдущую директиву RewriteCond.

Переменные записываются в виде %{ИМЯ_ПЕРЕМЕННОЙ}. Наиболее часто используются следующие переменные:

  • QUERY_STRING (параметры запроса),
  • REMOTE_ADDR (IP-адрес посетителя),
  • REMOTE_HOST (имя хоста посетителя),
  • REMOTE_USER (имя пользователя, если он прошел авторизацию),
  • REMOTE_METHOD (обычно GET или POST),
  • PATH_INFO (путь к файлу веб-страницы),
  • HTTP_USER_AGENT (содержимое http-заголовка User-Agent),
  • HTTP_REFERER (содержимое http-заголовка Referer),
  • HTTP_COOKIE (содержимое http-заголовка Cookie),
  • HTTP_HOST (имя хоста веб-сайта),
  • TIME_YEAR (все переменные TIME_* хранят разбитые на части текущие дату и время), TIME_MON, TIME_DAY, TIME_HOUR, TIME_MIN, TIME_SEC, TIME_WDAY,
  • REQUEST_URI (строка запроса без имени хоста и параметров запроса),
  • REQUEST_FILENAME (имя файла из REQUEST_URI),
  • THE_REQUEST (полная строка запроса в том виде, в котором ее присылает браузер посетителя).
  • Помимо стандартных переменных можно проверять содержимое любого http-заголовка: %{HTTP:Название-Заголовка}.

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

  • =ABC — значение переменной должно быть лексически равно строке ABC;
  • >ABC — значение переменной должно быть лексически больше строки ABC;
  • <ABC — значение переменной должно быть лексически меньше строки ABC;
  • -d — должен существовать каталог, имя которого совпадает со значением переменной;
  • -f — должен существовать файл, имя которого совпадает со значением переменной;
  • -s — должен существовать файл ненулевой длины, имя которого совпадает со значением переменной;
  • -l — должен существовать симлинк, имя которого совпадает со значением переменной;
  • -F— должен существовать файл, имя которого совпадает со значением переменной, и этот файл должен быть доступен по внешней ссылке на данный веб-сайт;
  • -U — должна быть доступна http-ссылка, имя которой совпадает со значением переменной.

Флагов может быть всего два: OR (объединение директив RewriteCond по ИЛИ, как было написано выше) и NC (отключение проверки регистра аналогично одноименному флагу для директивы RewriteRule).

И, наконец, примеры применения:

# Пример 1. Жесткий запрет посещений нашего веб-сайта для робота поисковой системы Google
 
RewriteCond %{USER_AGENT} Googlebot
RewriteRule .* - [F]
 
# Другой вариант возвращает вместо ошибки 403 (FORBIDDEN) ошибку 404 (NOT_FOUND)
 
RewriteCond %{USER_AGENT} Googlebot
RewriteRule .* - [R=404]
# Пример 2. Есть два каталога /home/site/storage1 и /home/site/storage2, в которых нужно искать запрашиваемые файлы
 
RewriteCond /home/site/storage1/%{REQUEST_FILENAME} -f
RewriteRule (.+) /home/site/storage1/$1 [L]
RewriteCond /home/site/storage2/%{REQUEST_FILENAME} -f
RewriteRule (.+) /home/site/storage2/$1 [L]
# Пример 3. Если ссылка не найдена на нашем веб-сайте, отправить посетителя на www.site.ru
 
RewriteCond %{REQUEST_URI} !-U
RewriteRule (.*) http://www.site.ru/$1 [R]
# Пример 4. Закрыть доступ к веб-сайту в рабочее время
 
RewriteCond %{TIME_HOUR}%{TIME_MIN} >1000
RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900
RewriteRule .* - [F]
# Пример 5. Есть скрипт, раз в сутки производящий оптимизацию базы данных. Если посетитель зайдет в
 этот момент на веб-сайт, то получит ошибку - вместо этого необходимо показать ему страницу с сообщением о том, 
что через пару минут все придет в норму. Оптимизирующий скрипт на время своей работы создает файл /home/site/optimizer.pid
 
RewriteCond /home/site/optimizer.pid -f
RewriteRule .* /optimization_message.html
# Пример 6. Посетители веб-сайта авторизуются при помощи стандартной авторизации (AuthType BasicAuth).
# Необходимо по ссылке /home/* показывать содержимое их домашних каталогов
 
RewriteCond %{REMOTE_USER} !=""
RewriteCond /home/(%{REMOTE_USER}) -d
RewriteRule (.*) /home/%1/$1

И в заключение вкратце упомянем еще о двух директивах преобразования ссылок, которые не входят в модуль mod_rewrite — это Redirect и RedirectMatch. Ими можно пользоваться, во-первых, как упрощенными вариантами директивы RewriteRule, а во-вторых, в случаях, когда модуль mod_rewrite по каким-то причинам отсутствует в вашей сборке веб-сервера Apache. Примеры:

# Обе директивы при «срабатывании» возвращают редиректы. 
# В качестве замены всегда должна использоваться абсолютная ссылка
 
# Обычный безусловный редирект:
Redirect /news http://www.site.com/cgi-bin/news.cgi
 
# Редирект с подстановкой:
RedirectMatch (.*\.gif)$ http://www.site.com/alt/path/to/gif/files$1

Возможно, на первый взгляд преобразование http-ссылок с помощью модуля mod_rewrite покажется очень сложной задачей, но на самом деле это не так: с опытом придет и понимание, и мастерство. Если вы внимательно читаете документацию, четко представляете необходимые преобразования ссылок и тщательно проверяете написанные вами правила, все будет работать правильно. Иначе и быть не может, не так ли?

Проброс TCP соединения через ICMP туннель

Утилита PingTunnel (http://www.cs.uit.no/~daniels/PingTunnel/) позволяет организовать
TCP тунель поверх ICMP ‘echo’ или 53 UDP порта. Подобное может оказаться полезным для обеспечения
работы клиента, для которого пакетным фильтром заблокирован весь трафик, кроме ICMP или 53 UDP порта.
Для работы PingTunnel необходим запуск прокси-процесса на удаленной машине
(не важно, под какой ОС, утилитой поддерживается даже Windows), имеющей выход в сеть.

Ставим ptunnel.
В Debian/Ubuntu:

   apt-get install ptunnel

В RedHat/CentOS/Fedora:

   yum install ptunnel

Во FreeBSD:

   cd /usr/ports/net/ptunnel && make && make install

На внешней машине, имеющей выход в сеть, запускаем icmp-прокси («-x пароль» можно не указывать,

но тогда пустит любого):

   ptunnel -x пароль

На локальной машине, на которой ничего кроме ICMP не работает, поднимаем туннель:

   ptunnel -p хост_прокси -lp локальный_порт_туннеля -da адрес_дальнейшего_проброса \
      -dp порт_дальнейшего_проброса -x пароль

Например:

    ptunnel -p proxy.testhost.ru -lp 2222 -da server.testhost.ru -dp 22 -x пароль

На proxy.testhost.ru у нас должен быть запущен icmp-прокси.
При коннекте на 2222 порт локальной машины мы будем переброшены на 22 порт хоста server.testhost.ru
Например, для входа на server.testhost.ru по SSH нужно набрать:

   ssh -p 2222 localhost

В случае проблем можно попробовать указать имя внешнего сетевого интерфейса через опцию «-c»,

например «-c eth1».
Для создания туннеля через 53 UDP порт на локальной и удаленной стороне нужно запустить ptunnel c опцией «-udp».

Источник

10 трюков в командной строке bash

1. Простой способ перехватить вывод и ошибки

Хотите направить stdout и stderr в один файл?

command &> file

Может вы разбираетесь в некой программе при помощи strace, и желали бы видеть системные вызовы вместе с ошибками программы?

strace badapp &> errors_and_output

Плюсы: легко запоминается, и проще чем «послать ошибки на вывод, а затем всё это в файл».
Совместимость: любой линукс.

2. Распараллеливание циклов

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

for HOST in $(< ListOfHosts); do ssh $HOSTsudo apt-get update& done

Может вам нужна куча ssh-туннелей одновременно:

for HOST in $(< ListOfHosts); do ssh -C -N -R 80:localhost:80 $HOST & done

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

Плюсы: сберегает метрическую туеву хучу (2/3 имперской туевой хучи) времени ожидания завершения.
Совместимость: любой линукс.
Минусы: у баша должны быть ограничения на количество одновременных задач, но пока автор (и переводчик) в них не упёрся.

3. Ловля утечек памяти через крон

Утечки памяти в линуксе нечасты, но бывают, особенно с бета-дистрибутивами или самодельным софтом. Часто выявить программу с подтёком не так-то просто. В линуксе есть программа Out-Of-Memory, позволяющая отыскивать и убивать такие процессы, но пока она сработает, система уже может начать сильно тормозить — настолько, что вы теряете терпение и перезагружаетесь.

Обычный способ узнать потреблении памяти программой это запуск top (или его графического эквивалента, наподобие System Monitor), и проверка Размера Резидентной Части (Res или RSS) интересующих процессов (память, отведённая программой, вам не нужна — утечки происходят от использования, а не от отведения, и программа может отвести (allocate) кучу памяти без вреда для системы). Большинство граждан не в курсе, что top можно запускать пакетно, что означает, что можно использовать cron и top для создания простого отчёта об использовании программой памяти:

  • запустите top
  • кнопками < и > добейтесь сортировки процессов по RSS (размер резидентной части)
  • нажмите W для записи конфигурации в файл
  • добавьте крон-задачу:
  • crontab - <<< '*/15 * * * * top -n 1 -b'

    И каждые 15 минут будете получать письмо с выводом топа.

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

    4. stdin прямо из командной стоки

    Не поняли, что это была за фигня (<<<)? Баш позволяет слать процессам стандартный ввод прямо из командной стоки.

    Плюсы: позволяет писать команды с командной стоки, даже для альтернативно дружественных программ, которые требуют ВСЁ со стандартного ввода. [Грозит кулаком MySQL-ю].
    Совместимость: bash 3 и новее.
    Минусы: всё ещё немало систем с bash 2.

    5. Установить первичный пароль, который надо поменять

    Многие организации имеют хорошие и надёжные политики паролей. Пароли хранятся на виндозных машинах. Линукс либо не не покрывается политикой, либо политика не соблюдается — люди не в курсе авторизации под линукс (большинство граждан не понимают PAM, а линуксовые админы часто не осознают, что линукс может чудесно авторизоваться через Active Directory), и было время, что разработчики OpenSSH не любили PAM (это с тех пор поменялось).

    Поставить пароль, который должен быть поменян при первом логине:

    umask u=rw,go=
    openssl rand -base64 6 | tee -a PasswordFile | passwd –stdin joe
    chage -d 0 joe

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

    Плюсы: пользователи не будут с начальным паролем бесконечно.
    Совместимость: любой линукс с обновлённым OpenSSH (если ваши пользователи заходят в первый раз по SSH). РедХат утверждает, что это всё ещё не работает в RHEL 3/4, но после приложения их обновлений, всё хорошо.
    Минусы: нет.

    6. Простое добавление публичного ключа на удалённый хост

    Для логина но новый хост по ключу надо сначала на этот хост записать публичную часть ключа. Конечно, это можно делать вручную, но вскоре это надоедает (и почему у ssh нет authorized_keys.d…), а ведь для этого есть специальная утилита:

    ssh-copy-id -i .ssh/id_rsa.pub hostname

    Введите пароль последний раз, ssh скажет:

    Now try logging into the machine, with “ssh ‘hostname’”, and check in:

    .ssh/authorized_keys

    to make sure we haven’t added extra keys that you weren’t expecting.

    Попробуйте. До свидания, пароли!

    7. Распаковка RPM без дополнительного софта

    На дебиано-подобных дистрибутивах это не проблема, потому что .deb файлы есть просто .ar архивы. Каждое руководство по РедХату упоминает rpm2cpio (идёт по умолчанию с rpm), но если честно, я не способен запомнить синтаксис cpio, античный формат, сейчас использующийся только, мм, пожалуй, только рпм-ом.

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

    mkdir /tmp/deleteme
     
    rpm -ivh –root /tmp/deleteme –nodeps –noscripts package.rpm

    8. Изменился ли файл с момента поставки

    Это простой способ узнать, не менялся ли файл из пакета. Сперва определите пакет, в который входит файл:

    dpkg -S /etc/foo/foo.conf
     
    rpm -qf /etc/foo/foo.conf

    Потом разверните оригинальный пакет при помощи tar (DPKg) или трюка с rpm, данного выше (RPM), и запустите:

    diff /etc/foo/foo.conf /tmp/deleteme/etc/foo/foo.conf

    И найдите разницу.

    Плюсы: быстрое нахождение плохих конфиг-файлов (strace тут тоже может пригодиться)
    Совместимость: любой линукс.
    Минусы: у вас остаётся больше времени на работе, чтобы читать Digg.

    9. — Первым делом отключите связь… Ало? ало? идиоты!

    Ковыряетесь в файрволе удалённо? Нервно как-то, правда? Не то нажал, и связь потеряна.

    Почему бы не откатить ошибку? Зарядите откат того, что вы собираетесь менять.

    at now + 5 minutes <<< 'cp /etc/ssh/sshd_config.old /etc/ssh/sshd_config; service sshd restart'

    Если ошибётесь, процесс выполнится и восстановит установки. А если не ошибётесь, запустите atq, и atrm <номер задачи> для удаления.

    Плюсы: прикрывает задницу на случай ошибки.
    Совместимость: любой линукс, в котором разрешён at, а он обычно да.
    Минусы: помнить, что это надо сделать перед рискованным действием.

    10. Открыт ли порт

    Хотите проверить, запущен ли сетевой сервис? Netcat с опцией -w (сколько ждать) будет полезен:

    nc -w 3 server ssh <<< ' '

    Соединиться на ssh порт на хосте по имени server, ждать 3 секунды перед тем, как послать, мм, ничего, и закрыть соединение. Был ли порт открыт, будет отражено в статусе nc.

    if nc -w 3 localhost 22 <<< ''&> /dev/null
    then
    echo 'Port is open'
    else
    echo 'Port is closed'
    fi

    Источник