Apt cacher ng alt linux

Apt-cacher-ng и Альт Линукс

При попытке использования кэша apt-cacher-ng для кэширования репозиториев Альта, может возникнуть следующая проблема при попытке обновление индексов (apt-get update):

Решение

Необходимо добавить следующие строки в файл конфигурации /etc/apt-cacher-ng/acng.conf :

А после перезапустить apt-cacher-ng.

Похожие статьи

Сборка Mono для Debian и Astra Linux

Команда Лаборатории 50 подготовила сборку Mono для Debian Buster и Astra Linux Special Edition 1.6. Состав В сборку входит: Mono 6.12; LibGdiPlus 6.0.6; Entity Framework 6; драйвер Npgsql Entity Framework.

ГосJava 2020.3

Изменения по сравнению с версией 2020.2 Java Runtime Environment Импортированы исправления из OpenJDK 8u262. Закрыты уязвимости: CVE-2020-14583: incomplete interface type checks in Graal compiler (Hotspot, 8236867). CVE-2020-14664: out-of-bounds write in.

Запуск нескольких экземпляров Tomcat

Запуск нескольких экземпляров Apache Tomcat Если есть необходимость запуска нескольких экземпляров сервера Apache Tomcat, то стандартные настройки и скрипты запуска не подходят. Ниже приведена инструкция и примеры скриптов для решения.

Источник

Apt-cacher-ng.

Есть у меня в хозяйстве админа один помощник, которому не находилось время сказать спасибо. Речь идёт об кэширующем сервисе для пакетов — apt-cacher-ng.

NG в имени — это Next Generation. Был такой предшественник apt-cacher, который требовал apache и тонну еще зависимостей. Apt-cacher-ng в этом плане молодчина. Нетребовательный сервис, который экономит админам время. Официально он экономит трафик, так как если у вас парк серверов под управлением Debian, Ubuntu, OpenSUSE, Fedora Core, Arch Linux, то первый сервер, как ледокол, вытащит кучу нехилых пакетов, а остальные сервера получат львиную долю пакетов из кэша. Но лично я хотел бы сказать спасибо именно за сэкономленное время. Чёрт с ним с трафиком. Без apt-cacher-ng смотреть на одно и тоже качаемое из официальных репозиториев в Интернете — удовольствия мало.

Естественно, что эффективность apt-cacher-ng возрастает с количеством однотипных серверов. Вот даю что есть у меня на дату написания статьи. Прошу заметить, что здесь статистика только по получению списков доступного софта из официальных репозиториев. На указанный период у меня не было серьёзных обновлений серверов и поэтому цифры такие «скромные».

Period	Cache efficiency
	Requests			Data
	Hits	Misses	Total	Hits	Misses	Total
2016-11-05 08:52 — 2016-11-06 08:52	644 (28.89%)	1585 (71.11%)	2229	53.21 MiB (74.55%)	18.16 MiB (25.45%)	71.38 MiB
2016-11-04 08:52 — 2016-11-05 08:52	987 (42.16%)	1354 (57.84%)	2341	48.72 MiB (66.33%)	24.73 MiB (33.67%)	73.45 MiB
2016-11-03 08:52 — 2016-11-04 08:52	554 (23.85%)	1769 (76.15%)	2323	61.39 MiB (54.77%)	50.69 MiB (45.23%)	112.07 MiB
2016-11-02 08:52 — 2016-11-03 08:52	890 (39.24%)	1378 (60.76%)	2268	56.89 MiB (69.30%)	25.20 MiB (30.70%)	82.09 MiB
2016-11-01 08:52 — 2016-11-02 08:52	575 (24.77%)	1746 (75.23%)	2321	58.72 MiB (68.57%)	26.92 MiB (31.43%)	85.63 MiB
2016-10-31 08:52 — 2016-11-01 08:52	631 (28.53%)	1581 (71.47%)	2212	27.74 MiB (65.03%)	14.92 MiB (34.97%)	42.66 MiB
2016-10-30 08:52 — 2016-10-31 08:52	781 (35.79%)	1401 (64.21%)	2182	48.56 MiB (78.22%)	13.52 MiB (21.78%)	62.08 MiB

Как говорится — мелочь, а приятно.

Детали рассусо́ливать не буду, так как сервис реально прост. Дам лишь пару советов. Сервис apt-cacher-ng работает отлично и с дефолтными настройками в /etc/apt-cacher-ng/acng.conf, просто запомните порт по умолчанию 3142.

Как указать клиентам использовать сервис? Есть 2 способа и каждый удобен в своём случае:

Можно создать файл /etc/apt/apt.conf.d/02proxy и в него вписать

Данный способ отлично подходит серверам, которые в консоли обновляются администратором вручную или через инструменты оркестровки типа puppet.
Второй способ лучше подойдёт для десктопных систем с графическими утилитами, которые в своей работе могут не опираться на apt, а работать с уровнем ниже — dpkg. Нужно просто модифицировать все адреса репозиториев в /etc/apt/sources.list и /etc/apt/sources.list.d/.

У клиентов в /etc/apt/sources.list меняем строки вида

Второй способ выручил в ситуации когда репозиторий доступен только по HTTPS и по умолчанию вы получите отлуп. Параметр PassThroughPattern: .* в /etc/apt-cacher-ng/acng.conf вас выручит, но сделает большую дыру в вашей системе, так как через такой прокси можно не только пакеты deb качать, но и не плохо так сёрфить в Интернете с помощью браузера. Можно уточнить параметр PassThroughPattern и не делать с помощью регулярного выражения .* в системе дыру, но есть способ проще и элегантнее. Репозиторий, доступный через HTTPS, можно указать вот так

Рекомендую также не стрелять себе в ногу — не обновляйте сервер с apt-cacher-ng через себя самого. Данный сервер должен обновляться напрямую через Интернет.

За долгий срок работы с apt-cacher-ng сталкивался с тем, что обновляться через него не получалось. Просто зайдите браузером на веб-страницу по адресу http://_IP_адрес_сервера_apt_cacher_ng:3142 и нажмите по очереди кнопки Delete unreferenced и Delete damaged.

Если до сего момента не использовали apt-cacher-ng, то при наличии даже пары машин, рекомендую приглядеться к нему и начать спасать свои нервы при установке или обновлении софта. Основной источник информации проекта Apt-Cacher-NG User Manual.

Источник

Настройка кеширующего прокси apt-cacher-ng для ускорения тестирования ansible ролей с Molecule, Gitlab CI и Docker

26.02.2017, 04:14 — 5 мин читать

В предыдущей статье я настраивал apt-mirror для тех же целей. У того способа нашлось несколько недостатков.

В статье ниже описано, как решить ту же проблему, используя apt-cacher-ng .

Tl;dr: на этот раз все получилось, этот способ меня устроил.

Настройка apt-cacher-ng

Здесь все довольно просто, проще, чем с apt-mirror .

В конфиге я задал пароль админа в /etc/apt-cacher-ng/security.conf , он дает право смотреть подробную статистику по cache-hit.

В /etc/apt-cacher-ng/acng.conf интересны следующие строчки:

• ExTreshold: 4 — устаревание кеша, в днях. Если файл ни разу не запрашивался дольше указанного времени, он будет удален. Я увеличил до 30 дней
• PassThroughPattern: .*:443 — нужно указать это, чтобы не было проблем с HTTPS репозиториями (об этом ниже).

В остальном стандартный конфиг делает следующее:

• запускает веб-сервер для всего мира на 0.0.0.0:3142
• хостит страничку и информацией о сервисе и статистикой на http://myserver.ru:3142
• хранит кеши в /var/cache/apt-cacher-ng

Также нужно отредактировать файл /etc/apt-cacher-ng/backends_ubuntu , удалив из него лишние зеркала и поставив главное зеркало в начало, иначе рискуете однажды получить 403 ошибку при установке одного из пакетов (об этом чуть ниже). У меня файл такой:

Подробности ремапинга можно почитать в документации. В 2 словах: когда клиент запрашивает пакет, apt-cacher-ng скачивает его не с репозитория, который прописан на клиенте, а с первого зеркала, указанного в файле ремапинга. Второй репозиторий по факту никогда не выбирается.

После этого можно перезапустить сервис:

Проверяем, что он поднялся, должен открыться урл http://myserver.ru:3142 .

Ошибка 403 при получении одного из пакетов

Через некоторое время использования я споткнулся об ошибку:

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

Оказалось, что репозиторий по умолчанию, который прописан в /etc/apt-cacher-ng/backends_ubuntu.default какой-то немного битый и пакет php-common не отдавал. Чтобы этого не произошло, нужно добавить свои репозитории в /etc/apt-cacher-ng/backends_ubuntu .

Ошибка 403 при доступе к HTTPS репозиториям

В этом месте тоже появляются ошибки, проявляются в ошибках 403 при apt-get update . Проблема здесь в том, что apt-cacher-ng не может прочитать зашифрованный трафик от https репозиториев, но все равно пытается. Этого можно избежать двумя способами:

• добавить такие репозитории в исключения
• использовать http репозитории в sources, а потом ремапить их на настоящие репозитории в apt-cacher-ng

Первый способ позволяет избежать изменения sources для системы-клиента apt-cacher-ng, второй — экономить трафик и для таких репозиториев. Я хочу, чтобы прокси работал максимально прозрачно, поэтому я использую первый способ. За то, какие репозитории обрабатывать, отвечает параметр PassThroughPattern . Нам нужно исключить из регулярного выражения все HTTPS репозитории.

О втором способе можно прочитать в этой статье.

Настройка на клиентах

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

На хосте я этого делать не стал, т.к. у меня там стоит старая Ubuntu 14.04, а тестирую я на Ubuntu 16.04. К слову, apt-cacher-ng это не волнует, он нормально кеширует новые пакеты, не смотря на то, что стоит на старой оси. Как я понимаю, его можно использовать и в смешанном режиме, то есть кешировать пакеты сразу от нескольких версий операционок, но я это не проверял.

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

Использование с Molecule, Gitlab CI и Travis CI

Не знаю зачем, но роли я тестирую сразу двумя CI: Gitlab и Travis. В связи с этим появляется проблема: нужно на Gitlab CI использовать один кеширующий сервер, при локальном тестировании другой, а для Travis CI убирать его.

Сложность в том, что Molecule не поддерживает разные конфиги, только умеет использовать в конфигах переменные окружения. Это я и использовал.

Смысл в том, что на разных CI в контейнер будут пробрасываться разные /etc/apt/apt.conf.d/00aptproxy , для Travis это будет просто пустой файл.

.gitlab-ci.yml я решил не менять, вместо этого я изменил способ регистрации раннеров в Gitlab CI, используются специальные раннеры с проброшенной переменной окружения:

Это сделано потому, что я еще запускаю локальные раннеры, хотелось сделать так, чтобы .gitlab-ci.yml подходил во всех случаях.

На локальной машине можно просто добавить переменные окружения через export прямо в терминале или добавить их в ваш

/.profile , тогда можно просто запускать molecule test и все будет работать.

Тестирование скорости

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

Роль	archive.ubuntu.org	apt-mirror	apt-cacher-ng	Travis CI:
ansible-role-common	8:04	6:18	6:30	4:32
ansible-role-mysql	3:41	3:22	3:26	3:46
ansible-role-zsh	3:16	2:54	2:56	4:08

Как видим, в скорости решение с apt-cacher-ng по сравнению с apt-mirror почти не теряет. Если не видно разницы, зачем тратить лишние 140 Гб?

Кстати, скорость тестирования увеличилась и на других способах, которые я описывал в прошлой статье: если тогда разница между способами была 20-30%, то теперь она сократилась до 10-20%. Это говорит о том, что если ничего не делать и пользоваться стандартными удаленными репозиториями, вы будете больше зависеть от внешних факторов.

Выводы

Минусы:

• Подходит только для множественного запуска однотипных установок, в моем случае так и есть
• Немного медленнее, чем при использовании зеркала, минусом это назвать сложно, т.к. разница всего 1-3%
• Нужно пробрасывать порт через фаервол, если хотите открыть прокси всему миру, я этого делать не стал 🙂

Плюсы:

• Хранит только нужные пакеты
• Кеширует не только пакеты из стандартного репозитория, но и внешние пакеты, которые вы добавляете в sources.list
• Не требует изменения sources.list
• Проше настраивать
• Не нужен веб-сервер (nginx)
• По умолчанию фаервол закрывает вас

Как видите, минусы надуманны, а плюсы реальны. На этом история ускорения скачивания пакетов закончена, но остается еще много интересных моментов в тестировании Ansible на Gitlab CI, продолжение следует.

Источник

Ubuntu Documentation

Apt-Cache-ng is A caching proxy. Specialized for package files from Linux distributors, primarily for Debian (and Debian based) distributions but not limited to those.

A caching proxy have the following benefits:

• Lower latency
• Reduce WAN traffic
• Higher speed for cached contents

Install package

Server configuration

After installation completes, the apt-cacher-ng will start automatically. Now open and edit the cache-ng configuration file located under /etc/apt-cacher-ng directory.

Set Username and password for webpage

Web server

Caching

Change path to where you like it to store it.

APT-cache-ng will store the files under diffrent repos:

Take not of the debrep, if defined it will merge diffrent Repository that matches Remap-debrep, and merge them together.

Tuning cache

Repository remapping

Repository remapping is a way to merge together all urls to the same repository.

On some restricted networks, it may be needed to enforce the use of predefined mirrors. If the ForceManaged option is set, only requests to URL matched in some Remap-. config is allowed.

If multiple Remap- lines for the same Repository are specified, the contents of both URL lists are merged.

Example with ubuntu, where a seperate file holds the upstream URLS, and all urls in file:ubuntu_mirrors or/ubuntu are using the TargetURLs

Pre caching

log setting

Change path to where you like it to store it.

Address and Port

Default Port:3142

Default: listens on all interfaces and protocols

To change port or hostname, uncomment. BindAddress can be multiple address that are resolved at start.

Upstream proxy

To use proxy uncomment and set your upstream proxy.

Client setup

There is multiple ways to set proxy for use:

• Hardcoded
• via DNS
• via multicast DNS
• via list

To force the client to use the proxy we can hardcodes the server name in the APT configuration and may not be appropriate if you change networks often.

Dynamic usage of proxy using DNS, and auto-apt-proxy

It is posible to use the local DNS server to lookup apt proxy server

DNS server setting

The DNS server needs to have a SRV record of _apt_proxy._tcp.$ .

Note: Current v13 auto-apt-proxy needs the $ to set via in hostname. sudo hostnamectl set-hostname client.example.com

The appropriate SRV record in dnsmasq.conf would look like this:

_apt_proxy._tcp.$ is the URL getting reqestetd.

apt-cacher-ng.example.com is the URL being returned, can be any valid URL

3142 is the port used, on the server being returned.

Client

Current v13 of auto-apt-proxy needs the $ to set via in hostname. sudo hostnamectl set-hostname client.$ , and hostname need to reflect in /etc/hosts:

The order is important, FQDN, then short.

client.$ , FQDN.

client, short hostname.

alternativt a host named apt-proxy can be defined in /etc/hosts.

This will add the following to /etc/apt/apt.conf.d/auto-apt-proxy.conf:

Dynamic usage of proxy using multicast DNS

With the use of Zero-configuration networking, it is posible for clients dynamicly use the local proxy server. This is useful for laptops but could be a security issue as anyone can then become a proxy for you and serve any content they wish (although SecureApt should still ensure a proper trust chain).

Server

To announce the service to the network, you install Avahi:

Client

On the client side we need squid-deb-proxy-client

This will add the following to /etc/apt/apt.conf.d/30autoproxy:

Verfie it is working

"--debug" flag can be used for more info.

Dynamic usage a list

If you have a list of server you like the client to try you can use.

This setting should contains the full path to the binary and cannot have arguments. The command should output the proxy to be used (example: http://10.0.0.1:3142).

Given the above information, a script could be created that tries a proxy before setting it. If no ProxyAutoDetecto proxy is available, a direct connection should be used.

Below is such a proxy detection script which tries the http://10.0.0.1:3142 and http://10.0.0.2:3142 proxies.

Put the code in /etc/apt/detect-http-proxy:

in /etc/apt/apt.conf.d/30detectproxy set:

Apt-Cacher NG (последним исправлял пользователь eiden 2021-08-07 20:24:49)

The material on this wiki is available under a free license, see Copyright / License for details
You can contribute to this wiki, see Wiki Guide for details

Источник

Читайте также:  Плагин mac os для canon