Файл robots.txt для WordPress

Эту статью я решил написать под впечатлением от прочитанного на западных блогах. Достаточно долгое время в сети существовал стереотип о правильной методике настройки файла robots.txt для WordPress. При котором старались максимально закрыть все дубли и другие не имеющие отношения к контенту страницы элементы.

На данный момент, у англоязычных блогеров набирает обороты совершенно противоположный тренд. Известный веб-мастер и SEO-специалист Yoast, автор популярного плагина для WordPress Yoast SEO, советует вовсе отказаться от использования robots.txt для запрета индексации контента.

Примера файл robots.txt, который использует Yoast на своем сайте:

User-Agent: *
Disallow: /out/

Как видите, для индексации закрыт всего лишь один раздел сайта. Со слов Yoast’а, это вынужденная мера, поскольку в разделе /out/ находится каталог партнерских ссылок. При желании вы можете ознакомится с его статьей по этому поводу.

Но не стоит вдаваться в крайности. Зачем беспечно полагаться на эвристические алгоритмы Google, если скрыть дубли в WordPress можно самостоятельно с помощью файла robots.txt. Таким образом, правильный robots.txt, является одним из механизмов для внутренней оптимизации сайта. И как по мне, глупо его не использовать.

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

Директивы robots.txt

Формат файла достаточно прост в освоении. Чтобы указать, на кого будут действовать правила, необходимо в robots.txt добавить директиву User-Agent с названием поискового робота. Мы можем задать различные правила для определенной поисковой системы. Для этого в директиве User-Agent, нужно указать имя робота. Но в большинстве случаев, будет достаточно использовать звездочку *, чтобы использовать общие правила для всех поисковых систем.

Далее идут директивы Allow или Disallow, которые указывают поисковой системе что можно индексировать, а к каким разделам доступ закрыт. Можно использовать регулярные выражения в названиях и именах файлов. Пример файла robots.txt:

User-Agent: *
Disallow: /*?
Disallow: /wp-admin/
Allow: /wp-content/uploads/

В примере выше, для всех роботов мы запрещаем индексацию результатов поиска и страницу авторизации панели управления WordPress. И разрешаем доступ поисковых систем к каталогу для загрузки изображений.

Для того чтобы указать ссылку на адрес файла XML-карты сайта, необходимо использовать директиву Sitemap как в примере ниже:

Sitemap: http://www.example.com/post-sitemap.xml

Исчерпывающую информацию по различным параметрам настройки robots.txt можно прочитать в руководстве от Google и Яндекс.

Файл robots.txt для WordPress

В рекомендациях специалисты Google советует как можно меньше ограничивать доступ поисковых роботов к содержимому сайта. В примере ниже файл robots.txt, который я использую на своем блоге:

User-agent: *
Disallow: /*?
Disallow: /20*
Disallow: /author/
Disallow: /wp-admin/
Sitemap: https://codebeer.ru/sitemap.xml

Чтобы убрать дубли, я запретил индексацию страниц поиска и архива. Дополнительно указал адрес к XML-карты сайта.

Можно добавить данные правила в robots.txt в корне сайта, либо использовать специальную функцию для WordPress. Для этого необходимо добавить в файл functions.php код из примера ниже:

add_filter('robots_txt', 'add_robotstxt');
function add_robotstxt($output){
    $output .= "Disallow: /*?n";
    $output .= "Disallow: /20*n";
    $output .= "Disallow: /author/n";
    $output .= "Disallow: /wp-admin/n";
    $output .= "Sitemap: https://codebeer.ru/sitemap.xmln";

return $output;
}

 

Используем пинг-сервисы

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

Функция оповещения пинг-сервисов работает следующим образом. Автоматически при появлении новой записи, WordPress посылает уведомление для поисковой системы по протоколу Weblogs.Ping:

POST /RPC2 HTTP/1.1
Host: rpc.pingomatic.com
Content-Type: text/xml
Content-length: 318

<?xml version="1.0" encoding="UTF-8"?>
<methodCall>
    <methodName>weblogUpdates.ping</methodName>
    <params>
        <param>
            <value>Пример сообщения для пинг-сервисов</value>
        </param>
        <param>
             <value>https://codebeer.ru/new-post/</value>
        </param>
    </params>
</methodCall>

Как правило, у каждого поисковика есть свои пинг-сервисы. По умолчанию WordPress использует пинг-сервис от Pingomatic. До недавнего времени я считал, что этого вполне достаточно. Но в процессе использования WordPress, я не заметил каких-либо видимых результатов от оповещения Pingomatic.

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

После того, как я добавил в настройках WordPress адреса пинг-сервисов Google и Яндекс, ситуация кардинально изменилась. Новый контент стал попадать в индекс в течении нескольких часов.

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

Добавить пинг-сервисы в WordPress

Чтобы добавить пинг-сервисы в WordPress, откройте меню «Настройки» — «Написание» — «Сервисы обновления», затем скопируйте следующие ссылки:

Пинг-сервис Яндекс:

http://ping.blogs.yandex.ru/RPC2

Пинг-сервис Google:

http://blogsearch.google.com/ping/RPC2

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

Настройка PageSpeed в Nginx

Дата: 12.10.2015Метки:

Ранее я уже описывал процесс установки Nginx с поддержкой модуля ngx_pagespeed из исходников. В этой статье я опишу процесс настройки параметров PageSpeed для Nginx. Модуль PageSpeed представляет собой набор фильтров для оптимизации и ускорения загрузки страниц и связанных с ними объектов: CSS, JavaScript, изображений.

Модуль PageSpeed имеет большое количество настроек для оптимизации содержимого страницы, которые дальше я буду называть фильтрами. Для удобства управления модулем, фильтры в PageSpeed объединены в логические структуры — уровни, которые можно задать с помощью параметра RewriteLevel.

Описание настроек PageSpeed

В зависимости от требуемого функционала модуля Nginx PageSpeed, с помощью директивы RewriteLevel мы можем задать три основных уровня его работы: CoreFilters, OptimizeForBandwidth и PassThrough.

  • CoreFilters — задает максимальный набор фильтров, которые по мнению разработчиков, подойдут для работы большинства сайтов;
  • OptimizeForBandwidth — задает минимальный набор фильтров, которые в основном ограничены оптимизацией внешних CSS и JavaScript файлов страницы;
  • PassThrough — «сквозной режим», данный уровень настройки полностью отключает все используемые фильтры PageSpeed.

Каждый из перечисленных уровней оптимизации, содержит стандартный набор фильтров для работы PageSpeed. Поэтому, вместо того чтобы самостоятельно перечислять все необходимые фильтры в конфиге Nginx, сначала укажем параметр RewriteLevel, а затем уже дополним его своими фильтрами.

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

С помощью EnableFilters или ForbidFilters можно  добавить или удалить выбранные фильтры. Директивы позволяют указать в качестве параметра название одного или нескольких разделенных запятыми фильтров:

pagespeed EnableFilters rewrite_css,rewrite_javascript;
pagespeed DisableFilters rewrite_css,rewrite_javascript;

Настройка PageSpeed в Nginx

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

Откройте файл nginx.conf:

nano /etc/nginx/nginx.conf

Чтобы включить PageSpeed в Nginx и задать параметры кэширования, необходимо указать следующие настройки:

pagespeed on;
# Путь к каталогу кэша
pagespeed FileCachePath "/var/run/pagespeed-cache/";
# Максимальный размер кэша
pagespeed FileCacheSizeKb 102400;
# Интервал для очистки кэша
pagespeed FileCacheCleanIntervalMs 360000;
# Максимальное количество дескрипторов
pagespeed FileCacheInodeLimit 500000;

Для улучшения производительность Nginx, мы будем хранить файлы кэша PageSpeed на RAM-диске. В Debian можно использовать каталог /var/run, который смонтирован в оперативной памяти как tmpfs. Размер кэша зависит от количества свободной памяти в системе.

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

Далее необходимо настроить фильтры PageSpeed для нашего сайта. Откройте конфигурационный файл виртуального хоста Nginx:

nano /etc/nginx/sites-enabled/default.conf

Мы задаем для RewriteLevel шаблон CoreFilters, который затем дополняем своими фильтрами:

server {
    listen       80;
    server_name  example.com;

    root   /www/example/html/;
    index  index.html index.htm;
    }

    # Настройки фильтров
    pagespeed RewriteLevel CoreFilters;
    pagespeed EnableFilters collapse_whitespace,remove_comments;
    pagespeed DisableFilters rewrite_images;
    # Адрес и директория сайта
    pagespeed LoadFromFile "http://example.com/" "/www/example/html/";
}

Дополнительно к CoreFilters, мы добавляем фильтры для минификации и удаления комментариев из HTML-кода страницы. Чтобы снизить нагрузку на сервер, я отключил фильтр для сжатия изображений, который по умолчанию включен в CoreFilters. Вы можете добавить или отключить любые фильтры по своему усмотрению. В процессе настройки PageSpeed, будет полезна таблица с описанием фильтров.

Следует отметить, что для оптимизации CSS и JavaScript файлов, необходимо в директиве LoadFromFile указать адрес и путь к каталогу вашего сайта.

Проверяем конфигурацию Nginx и применяем настройки:

nginx -t
service nginx reload

Для проверки работы PageSpeed, необходимо предварительно очистить кэш браузера. Для Chrome можно использовать горячие клавиши Ctrl + F5.

Из своего опыта, могу отметить следующее. Фильтры rewrite_css и combine_javascript не всегда объединяют несколько файлов в один. Но можно убедиться, что данные фильтры работают, если загрузить на сервер специально подготовленную страницу.

Свои имена для NS-серверов

Дата: 11.10.2015Метки:

После регистрации домена, для того чтобы привязать доменное имя к IP-адресу сервера, необходимо указать для него минимум два NS-сервера. Сервера DNS хранят информацию о зоне (субдомены, MX и текстовые записи) и выдают эту информацию по запросам.

Независимо от того, свои или чужие NS-сервера мы используем, можно настроить записи в DNS таким образом, чтобы в WHOIS отображались названия NS-серверов на основе нашего доменного имени:

domain:        example.com
nserver:       ns1.example.com.
nserver:       ns2.example.com.

Чтобы использовать свои имена для NS-серверов, рассмотрим последовательность действий на примере DNS-хостинга Яндекс. Для начала нам необходимо делегировать свой домен на DNS от Яндекс.

Для этого в панели регистратора, необходимо изменит NS-сервера для вашего домена на следующие:

dns1.yandex.net.
dns2.yandex.net.

После того как домен будет делегирован на Яндекс, в редакторе DNS необходимо добавить следующие записи типа A:

ns1	A	213.180.204.213
ns2	A	93.158.134.213

Таким образом, для нашего домена мы добавили два субдомена ns1.example.com и ns2.example.com, которые мы закрепили за адресами DNS-серверов Яндекс.

Теперь в редакторе DNS необходимо заменить NS-сервера Яндекс dns1.yandex.net и dns2.yandex.net. на свои:

@	NS	ns1.example.com.
@	NS	ns1.example.com.

Осталось только поменять NS-сервера у регистратора домена. Для этого в панели где зарегистрирован ваш домен, нужно указать свои названия NS-серверов и прописать закрепленные за ними IP-адреса DNS Яндекс:

ns1.example.com       213.180.204.213
ns2.example.com       93.158.134.213

После чего необходимо дождаться обновления записей.

Удалить неиспользуемые теги в заголовке WordPress

В содержимом HTML-документа, генерируемого WordPress, можно заметить множество служебных тегов, которые отображаются в заголовке head страницы. Эти теги достаточно редко используются и, как правило, абсолютно бесполезны для посетителей сайта или поисковых систем. Кроме того, некоторые мета-теги противоречат правилам безопасности и могут нанести вред для сайта WordPress.

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

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

<link rel="profile" href="http://gmpg.org/xfn/11">
<link rel="pingback" href="xmlrpc.php">
<link rel="alternate" type="application/rss+xml" title="Лента" href="/feed/"/>
<link rel="alternate" type="application/rss+xml" title="Лента комментариев" href="comments/feed/"/>
<link rel="EditURI" type="application/rsd+xml" title="RSD" href="/xmlrpc.php?rsd"/>
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="wp-includes/wlwmanifest.xml"/>
<meta name="generator" content="WordPress 4.3.1"/>
<link rel='prev' title='' href=''/>
<link rel='canonical' href=''/>
<link rel='shortlink' href=''/>

Можно автоматически удалить неиспользуемые теги из заголовка WordPress с помощью специального плагина WP Head Cleanup. Для этого после установки необходимо выбрать соответствующие опции в настройках плагина. Я же предпочитаю, по возможности, не использовать плагины вообще.

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

— meta name=’generator’
Убрать версию WordPress из заголовка страницы:

remove_action( 'wp_head', 'wp_generator' );

— link rel=’wlwmanifest’
Убрать ссылку для редактирования клиентом Windows Live Writer:

remove_action( 'wp_head', 'wlwmanifest_link' );

— link rel=’EditURI’
Убрать ссылку для редактирования внешними сервисами:

remove_action( 'wp_head', 'rsd_link' );

— link rel=’shortlink’
Убрать вывод коротких ссылок:

remove_action('wp_head', 'wp_shortlink_wp_head');

— link rel=’canonical’
Убрать вывод канонических ссылок:

remove_action('wp_head','rel_canonical');

— link rel=’prev’ и link rel=’next’
Убрать вывод ссылок на предыдущую / следующую запись:

remove_action('wp_head','adjacent_posts_rel_link_wp_head');

— RSS
Убрать вывод ссылок на основную и дополнительную ленту:

remove_action('wp_head','adjacent_posts_rel_link_wp_head');
remove_action('wp_head','feed_links_extra', 3);

— REST API
Убрать вывод ссылки REST API:

remove_action('xmlrpc_rsd_apis', 'rest_output_rsd');

— link rel=’profile’
Убрать в файле header.php ссылку на адрес профиля метаданных:

<link rel="profile" href="http://gmpg.org/xfn/11">

— link rel=’pingback’
Убрать в файле header.php ссылку на пингбэк-сервер:

<link rel="pingback" href="xmlrpc.php">

Следует отметит, что код из примеров удаляет неиспользуемые теги в заголовке head, при этом, никак не затрагивает функционал самого WordPress.

Установка пакетов в Debian

Дата: 09.10.2015Метки:

В Debian установка пакетов выполняется двумя способами. Первый вариант — из подключенных репозиториев. Второй — установка deb-пакета с локального раздела диска. В зависимости от типа установки, используется программы APT или DPKG.

Установка пакетов в Debian с помощью APT

Команда apt-get использует базу пакетов, автоматически определяет и устанавливает все необходимые зависимости. Для установленных через apt-get пакетов, существует механизм автоматического отслеживания и установки обновлений. Поэтому, в большинстве случаев рекомендуется установка пакетов в Debian с помощью команды apt-get.

В Debian установка пакетов из репозитория начинается с обновления локального кэша APT:

apt-get update

В результате работы, команда обновит информацию о всех пакетах, которые содержатся в репозиториях. Далее, по своему усмотрению мы можем использовать одну из команд ниже.

APT: установка пакетов
В Debian установка пакетов выполняется с помощью команды:

apt-get install mysql-server

APT: поиск пакетов
C помощью простых текстовых запросов можно использовать APT для поиска пакетов в репозитории:

apt-cache search mysq-server

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

apt-cache depends mysq-server

Установка deb-пакета с помощью DPKG

Если по какой-либо причине, необходимого нам пакета нет в репозиториях, в таком случае, можно установить deb-пакет используя команду dpkg.

Самостоятельно DPKG не умеет загружать необходимые для работы пакета зависимости. Также, отсутствует механизм для обновления пакетов. Как правило, команду dpkg используют в тех редких случаях, когда необходима установка deb-пакета с локального диска.

DPKG: установка deb-пакета

dpkg -i /tmp/mysql-server-5.5.deb
apt-get -f install

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

Удалите код препятствующий отображению

Если вам когда-либо приходилось анализировать свои сайты с помощью сервиса Google PageSpeed Tools, то вы наверняка уже сталкивались с данной рекомендацией: «Удалите код JavaScript, препятствующий отображению».

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

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

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

Как удалить код, препятствующий отображению страницы

Перейдем к технической стороне решения вопроса. Чтобы убрать данное предупреждение: «Удалите код JavaScript, препятствующий отображению», нужно убрать подключение скриптов внутри тега <head>, а затем подключить их в низу страницы. Но не спешите слепо выполнять данную рекомендацию.

В зависимости от размера скрипта и его функций, существует следующие рекомендации по размещению JavaScript:

  • скрипты участвующие в процессе отображении страницы необходимо подключать внутри тега <head>;
  • если скрипт не участвует в процессе отображения страницы, необходимо его перенести в страницы;
  • скрипты небольшого размера лучше добавить в содержимое HTML-документа;
  • используйте атрибут async для  асинхронного вызова JavaScript.

Пример асинхронного вызова скрипта:

<script async src="code.js">

Как перенести скрипты в подвал WordPress

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

Для скриптов, которые необходимо выводить в подвале WordPress, необходимо в файле functions.php добавь параметр true в конец вызова функции wp_register_script.

Формат вызова функции wp_register_script():

wp_register_script( $handle, $src, $deps, $ver, $in_footer );

Для вывода скрипта в подвале WordPress, необходимо установить true в значении параметра $in_footer, как это сделано в примере ниже:

function wpb_adding_scripts() {
    wp_register_script('my-script', get_template_directory_uri() . '/js/my-script.js','','1.0', true);
    wp_enqueue_script('my-script');
}
add_action( 'wp_enqueue_scripts', 'wpb_adding_scripts' );

Как вариант, чтобы разместить скрипт в подвале WordPress, можно выполнить повторную регистрацию JavaScript:

function wpb_adding_scripts() {
    wp_deregister_script('my-script');
    wp_register_script('my-script', get_template_directory_uri() . '/js/my-script.js','','1.0', true);
    wp_enqueue_script('my-script');
}
add_action( 'wp_print_scripts', 'wpb_adding_scripts' );

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

function footer_enqueue_scripts() {
    # Удаляем JavaScript из заголовка
    remove_action('wp_head', 'wp_print_scripts');
    remove_action('wp_head', 'wp_print_head_scripts', 9);
    remove_action('wp_head', 'wp_enqueue_scripts', 1);
    # Выводим в footer
    add_action('wp_footer', 'wp_print_scripts', 5);
    add_action('wp_footer', 'wp_enqueue_scripts', 5);
    add_action('wp_footer', 'wp_print_head_scripts', 5);
}
add_action('after_setup_theme', 'footer_enqueue_scripts');

Список установленных пакетов в Debian

Дата: 08.10.2015Метки:

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

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

В большинстве случаев, когда необходимо просмотреть информацию о установленных пакетах в Debian, будет удобно использовать команду:

dpkg -l

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

# Для точного название пакета
dpkg -l mc
# Да отображения пакетов по маске
dpkg -l php*

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

dpkg -L mc

Используем dpkg для бэкапа и установки пакетов

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

dpkg --get-selections > ~/package.list

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

dpkg --set-selections < ~/package.list
apt-get update && apt-get -u dselect-upgrade

JQuery: Открыть ссылку в новом окне

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

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

Чтобы браузер самостоятельно открывал ссылки в новом окне, необходимо использовать специальный атрибут target="_blank". Как быть, если по какой-либо причине, ранее вы не использовали данный атрибут. В данной ситуации будет полезен небольшой JavaScript, который навсегда избавит вас от данной проблемы.

В шаблоне вашего сайта, перед закрытием тега </body> необходимо добавить код из примера ниже. Теперь, вне зависимости от наличия атрибута target="_blank", скрипт автоматически будет открывать исходящие ссылки в новой вкладке браузера. При этом, навигация по внутренним ссылкам сайта останется без изменений.

<script type= "text/javascript">
$('a').each(function() {
    var a = new RegExp('/' + window.location.host + '/');
    if(!a.test(this.href)) {
         $(this).click(function(event) {
         event.preventDefault();
         event.stopPropagation();
         window.open(this.href, '_blank');
         });
    }
})
</script>;

Скачать пакет из репозитория Debian

Дата: 05.10.2015Метки:

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

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

Как вариант, можно просто скачать deb-пакет из репозитория Debian без его последующей установки. Для этого у пакетного менеджера apt-get в Debian есть специальная опция download, которая позволяет скачать пакет в текущую директорию. Для того чтобы скачать пакет из репозитория Debian необходимо выполнить команду ниже:

cd /tmp
apt-get download package-name

Если пакет уже был ранее установлен в системе, можно скопировать deb-файл из каталога:

cd /var/cache/apt/archives/