Проблемы с mirror.mephi.ru

самый надежный - яндекс :)

надёжный быть может, по скорости не уверен…

Напиши им

• mirror@lists.ut.mephi.ru

Они сами про это тут просят

• https://ut.mephi.ru/services/mirror-mephi-ru

по скорости

нивелируется локальным кеширующим прокси, например, apt-cacher-ng

Заработало. Но всё равно можно написать и сказать что был отвал. Вдруг проспали, а метрики не ведут

Забавно, если тред увидели… :D

Нивелируется, но не всегда уместно.

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

у меня уже недели две как недоступен, убрала его из списка
еще неделю назад gentoo.org был недоступен пару дней, соответственно не работало обновление ключей через WKD
(emerge --sync или даже emerge-webrsync)

меня уже ничего не удивляет...

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

sudo apt update; sudo apt-get upgrade --download-only

с низким приоритетом и все новенькие пакетики будут прокачиваться в кеш заранее :) скорость будёт ажпесец…

очень жалею, что к пакетной ситеме так и не прикрутили п2п-облако… былоб жутко удобно.

очень жалею, что к пакетной ситеме так и не прикрутили п2п-облако… былоб жутко удобно.

Так был жэ apt-p2p. Но увял в связи с невостребованностью. Когда последний раз его трогал (давно) — скорость была ниже, чем с зеркал.

К тому же apt-cacher-ng забагован, а баги чинить некому потому что заброшен.

ты чо, кажный день обновляешься

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

Тоже на такое попадал при большом количестве машин.

Если держать, скажем, 10 машин

то надо использовать

https://github.com/soulteary/apt-proxy

Нафиг твой прокси, debmirror/aptmirror наше все.

вы ошиблись, он не мой

По-моему, mirror.mephi.ru не работал с позапрошлой пятницы (14 августа) до сегодняшнего дня: https://mirror-master.debian.org/status/mirror-info/mirror.mephi.ru.html

«скрипты спасут отца русской демократии» :)
я б просто расшарил директорию кеша с основной машины на все подведомственные…

@sn4il, да, система получилась неидеальная, что жаль. иэх, а так было бы удобно. автоматическое определение всего облака репозиториев, отбор близких. на работе поставил п2п-апт и пофиг на весь мир.

именно так, лежал с неделю.

Плохая идея, у пакетов из кеша по-моему контрольные суммы не проверяются.

кажись проверяют. вообще недокачанные пакеты в partial лежат. плюс еще проверку dpkg делает. как универсальный вариант тип источника file.

ЧЯДНТ

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

К тому же apt-cacher-ng забагован, а баги чинить некому потому что заброшен.

Хм. А давно его бросили то? Вроде в репах 13-го Debian он есть.

2024-07-22 - Eduard Bloch <blade@debian.org>
apt-cacher-ng (3.7.5-1) unstable; urgency=medium
* New upstream version
+ redirection location fixes (closes: #1074404)
+ increased safety abort timeout (closes: #1006925)
+ time_t overflow on certain architectures fixed (closes: #1073970)

dpkg точно не делает, ему не с чем сравнивать, информация о репозитории есть только у apt

Сам по себе .deb проверить невозможно, его надо сравнивать с таблицами пакетов и хешей, скачанными при apt-get update.

в control есть md5sums.
недокачанный пакет из partial не перемещается. емнип перед перемещением апт еще и проверяет подпись пакета.

Причём тут control? Речь про проверку суммы sha256(file.deb), эта сумма есть только у apt.

А почему partial? Если ты просто расшарил кеш то пакеты не в partial будут.

Причём тут control? Речь про проверку суммы sha256(file.deb), эта сумма есть только у apt.

Они не могут быть в control, так как нужная контрольная сумма может появится только после сборки самого deb пакета.

А почему partial? Если ты просто расшарил кеш то пакеты не в partial будут.

Ну пока они не докачились они будут лежать в partial а это другая директория.

P.S. Че то я не пойму мне то можно писать в тему, то бан по ip, непонятно как то :( Я же на месте не сижу то с одного ip захожу, то с другого.

partial - специальная поддиректория в /var/cache/apt/archives. в нее качаются пакеты.
только после окончания закачки и проверки целостности пакет перемещают в /var/cache/apt/archives для дальнейшего использования.
если расшарить/подключить /var/cache/apt/archives, то недокачанные пакеты так и будут находится в /var/cache/apt/archives/partial
что непонятно ??

Непонятно, зачем ты приплёл сюда partial, я про него ничего не писал. Речь была про скачанные пакеты, которые перед переиспользованием на другом компе в итоге не будут проверяться.

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

Если пакет скачается с ошибкой то он никогда не попадет в директорию расшареного кеша.

Зря тебя из бана убрали. Прекращай засорять тему, глупый анонимус, ты не в теме.

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

неделю назад gentoo.org был недоступен пару дней

И чего, вы теперь подключаетесь к репозиториям команды Calculate?

Хорошо, сиди дальше в дырявой инфраструктуре, где заражение одного компа автоматом заражает всю сеть. Но другим такое не надо советовать.

ну коль ты такой умный и безопастный
https://xakep.ru/2006/12/16/35784/
распечатай и читай по десять раз на день, отбивая поклоны перед компьютером !! :)

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

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

тут заява явно в другом :) а вдруг кто-то страшный и ужастный подсунет левый пакет в кеш. к примеру с вирусом :)

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

Хм. В Debian официальные iso, не содержат файлы Release.gpg и если ты ставишь систему с локального диска то выключается проверка цифровой подписи устанавливаемых пакетов ;(

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

Потому что подпись стоит на контрольной сумме образа диска, и считается, что ты проверяешь ее после создания read-only носителя.

так-то подпись есть, и репозиторий есть :)
в образе по пути *.iso\dists%distr%\ имеется мааааленький полноценный репозиторий с Release и Release.gpg
но да, исполняемое содержимое установочного комплекта идет без подписей, и копируется оно в корневой раздел устанавливаемой системы напрямую.

очень жалею, что к пакетной ситеме так и не прикрутили п2п-облако… былоб жутко удобно.

С помощью metalink 1 пакет можно качать с нескольких зеркал.

Так был жэ apt-p2p. Но увял в связи с невостребованностью. Когда последний раз его трогал (давно) — скорость была ниже, чем с зеркал.

потому что зеркала не работали в роли раздающих.

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

апт-п2п сколь понял был полностью новой системой. и когда автору стал неинтересен - уплыл вниз по стиксу…

http_proxy=ip:port emerge --sync

как вариант

fast-sync() {
    PORTAGE_REPOSITORIES="[gentoo]
location = /var/lib/repos/gentoo
sync-type = rsync
sync-uri = rsync://rsync.gentoo.org/gentoo-portage
sync-openpgp-key-refresh = no" emerge --sync "$@"
}

sync-openpgp-key-refresh = no

Выглядит опасно

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

Это всего-лишь не обновляет (отозванные) ключи с WKD, подпись портежа по прежнему проверяется установленными в системе ключами PGP.
Опасно становится при постоянном отключении, а если через функцию bash отключить для одноразовых применений, то вполне можно. Я sync делаю каждый день, часто и не один раз, так что каждый раз проверять WKD нет особого смысла.

И да http_proxy для emerge --sync работает только для WKD, для rsync надо RSYNC_PROXY (с разрешенным туннелем на 873 порт

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

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

Вот да, тоже замечал что по скоростям с ними всё прекрасно.

Но истинная причина в другом — оно много где дефолтом идёт, и не всегда об этом помнишь. Хотя, справедливости ради, не помню за ними сбоев вообще.