Замена apt-mirror`у
apt-cacher — утилита для Debian-подобных дистрибутивов использующих apt в качестве установщика пакетов. Она кеширует файлы, которые скачивает пользователь с офф. зеркала обновлений и при следующем запросе выдает их из своего кэша.
В чем плюсы apt-cacher`a перед apt-mirror`ом?
Во-первых, в экономии трафика. Зачем качать один и тот же пакет несколько раз, если его уже скачал ваш коллега? Таким образом экономия трафика растет пропорционально количеству народу в конторе использующих *buntu.
Во-вторых, в экономии места на ЖД сервера, на котором установлен apt-cacher. Ведь зачем хранить 22 Гб пакетов на ЖД, если из них используются максимум 10Гб?
В-третьих, в скорости получения обновлений. Сколько раз вы обновляете свое зеркало обновлений? 1 раз в день? Apt-cacher позволяет получать обновления по мере их появления на офф. зеркале. Когда пользователь делает запрос на обновление(apt-get update) apt-caсher лезет на офф. зеркало проверить, нет ли обновлений того что у него лежит в кеше.
Безусловно у apt-cacher есть и минусы.
Первый минус — apt-cacher распределяет закешированные файлы по своей структуре, отличной от структуры debian-репозиториев. Но эту проблему можно решить, если вам важно сохранить структуры репозитория, это описано ниже.
Второй минус — необходимо наличие Веб-сервера Apache. Тут, к сожалению так просто проблему не решить, но я не думаю, что это существенная проблема :)
Установка и настройка apt-cacher`a
Сама установка довольно банальна для debian-пакетов
sudo apt-get install apt-cacher
Создадим папку для хранения кэша(т.е. самих пакетов) и назначим ей права
sudo mkdir /var/cache/apt-cacher
sudo chown www-data:www-data /var/cache/apt-cacher/*
Вы можете создать папку в любом месте
под юзером и группой www-data будет запускаться наш apt-cacher, так же под ним надо будет запускать Apache.
С настройкой немного сложнее, разбирать настройку самого apt-cacher`a, будем на примере.
Откроем для редактирования файл /etc/apt-cacher/apt-cacher.conf:
sudo nano /etc/apt-cacher/apt-cacher.conf
Рассмотрим пример конф. файла:
cache_dir=/var/cache/apt-cacher #директория которую мы создали и в котрой будет храниться кэш.
admin_email=root@localhost # мыло админа :)
daemon_port=9999 #порт на котором будет висеть наш apt-cacher
group=www-data #группа под которой будет запускаться наш apt-cacher
user=www-data #юзер под которой будет запускаться наш apt-cacher
allowed_hosts=* #хосты доступ с которых разрешен на наш сервер(по-умолчанию разрешено всем)
denied_hosts= #соответственно запрещен.
generate_reports=1 # раз в сутки будут генерироваться отчеты об использовании apt-cacher`a(1-генерить, 0 - нет)
clean_cache=1 #Очистка кэша раз в сутки,
offline_mode=0 #Если 0, то с apt-cacher будет тянуть обновления с офф. сервера, если 1, то раздавать только то что у него в кэше
logdir=/var/log/apt-cacher #папка в которой будут храниться логи доступа к apt-cacher`у
expire_hours=0 # apt-cacher может работать в двух режимах. В первом режиме сервер будет сравнивать expire_hours со временем последнего обновления пакета, и если оно становится меньше, то искать на офф. зеркале обновление для этого пакета, Во-втором режиме сервер будет сравнивать напрямую с офф.сервером, но в этом случае бОльшая вероятность рассинхронизации данных кэша и индексных файлов. Я всегда использую второй вариант, т.к. Для меня важнее получить вовремя обновление. 0 — Второй режим, все что больше 0 — то часы первого режима.
http_proxy= #адрес вашего прокси-сервера(если он у вас есть)
use_proxy=1 #Использовать(1) или нет(0) прокси.
http_proxy_auth= #Авторизация на прокси(формат: user:password)
use_proxy_auth= # Использовать ли авторизацию? (1-да, 0-нет)
limit=0 #Ограничитель скорости. 0 — нет ограничений. 250K — 250кбит/с, 2m — 2мбит/с
debug=0 #Уровень отладки. 0 — маленький лог файл, 1 — большой.
path_map = ubuntu archive.ubuntu.com/ubuntu ; canonical archive.canonical.com/ubuntu ; medibuntu packages.medibuntu.org/ ; #Самый интересный параметр. Настройка зеркал обновления, т.е. Откуда будут тянуться обновления.
Думаю с настройкой самого apt-cacher`a все(ну или почти все) ясно.
Теперь приступим к настройке Apache. Процесс настройки самого Apache я описывать не буду, в Сети много хороших руководств. Для работы всего этого должен быть установлен Perl и включен ExecCGI. Пример моего конфига(файл: /etc/apt-cacher/apache.conf
Alias /apt-cacher /usr/share/apt-cacher/apt-cacher.pl
Options ExecCGI
AddHandler cgi-script .pl
AllowOverride None
order allow,deny
allow from all
Вот. Настройка конф. файлов закончена. Теперь, думаю, самое время приступить к настройке рабочих станций, но для начала опишу как все-таки конвертнуть то, что было в кэше apt-mirror`а в apt-cacher.
Apt-mirror > apt-cacher
У apt-cacher`a есть perl скрипт для конвертации пакетов в формат apt-cacher`a, имя ему apt-cacher-import.pl, и лежит он в /usr/share/apt-cacher. Пользоваться им следующим образом:
/usr/share/apt-cacher/apt-cacher-import.pl -r -c /etc/apt-cacher/apt-cacher.conf /var/my_repos
-r — рекурсивный обход каталога
-c — не обязательный параметр, в котором указывается путь к конф. файлу.
/var/my_repos — директория к репозиторию формата apt-mirror(обычный дебиановский формат репозитория).
В результате этой команды, в папку /var/cache/apt-cacher будут скопированы и переведены в нужный формат все пакеты, которые будут найдены в /var/my_repos
Если вам необходимо оставить дебиановский репозиторий, при этом чтобы репозиторий apt-cacher`a не занимал дополнительного места, к команде добавьте -s, тогда скрипт просто сделает сим-линки на пакеты. НО! Если вы после этого удалите дебиановский репозиторий, то пакеты для apt-cacher`a так же будут не доступны(это же обычные сим-линки)
Если же вы использовали apt-proxy, то у apt-cacher`a тоже имеется скрипт для перевода его репозитория в свой. Скрипт лежит: /usr/share/apt-cacher/apt-cacher/apt-proxy-to-apt-cacher.pl.
Запуск демона и настройка клиентских машин.
Запустить сервер как обычно просто:
sudo /etc/init.d/apt-cacher start
Если вы не допустили синтаксических и иных ошибок в конфигурациях apache и apt-cacher`a, то сервер радостно запуститься, о чем сообщит вам не менее радостным сообщением [OK], если же произошла ошибка, то сервер сделает грустную гримасу и сообщит [FAIL]. Тогда вам придется все перечитать заново и возможно немного по`google`ить.
Чтобы проверить запуск можно зайти на localserver:9999 (где localserver — сервер на котором запущен apt-cacher).
Настройка клиентов
Собственно нужно всего лишь добавить 1 строку(и закоментировать остальные) в файл /etc/apt/sources.list:
deb localserver:9999/ubuntu intrepid multiverse restricted main universe
Тут все как и в обыном репозитории, указываете что вам нужно обновлять, какой дистрибутив и т.п. Localserver — это сервер на котором запущен apt-cacher.
Если вы включили статистику, то её можно посмотреть localserver:9999/reports
Ну вот вроде бы и все :)
В качестве стандартного шрифта, как правило, использовался шрифт с засечками (Times), причём достаточно крупного кегля, чтобы на тогдашних мониторах текст читался легко с очень низким разрешением и сильными искажениями вследствие выпуклости поверхности экрана. В разных операционных системах этот шрифт был реализован по-разному.
При отсутствии антиалиасинга (алгоритма экранного сглаживания) засечки-серифы у букв слипались в какую-то невообразимую кашу, и практически невозможно было что-либо разобрать. Да и в крупных размерах (
Впрочем, броузеры того времени позволяли принудительно выбрать в качестве шрифта по умолчанию любую установленную в системе гарнитуру. В Windows можно было использовать помимо антиквенного Таймса гротесковый шрифт Arial (в определённой степени — не самая удачная переделка легендарной Гельветики), моноширинный Courier и полурукописно-насмешливый ComicSans. 
И если Courier оказался весьма удачным вариантом для отображения программного кода (этот шрифт и поныне является фаворитом в программистской среде и используется по умолчанию в большинстве современных сред программирования), то Arial лишь немногим улучшал ситуацию по сравнению с Times New Roman. В системах Unix использовался шрифт Helvetica (более-менее близкий к оригинальному шрифту от Linotype). А у пользователей продукции Apple в ходу была гарнитура Geneva.
В спецификацию HTML были внесены корректировки, благодаря которым появилась возможность указывать несколько шрифтов и объединяющее семейство на то случай, если конкретного шрифта в системе не окажется. Например, можно было написать так: 
В 1996 году были разработаны и включены в состав Windows новые системные шрифты Verdana, Tahoma и Georgia.
Действительно, в некрупных кеглях (даже вплоть до кеглей в 10 или даже 9 пикселей) эти гарнитуры читались гораздо лучше, хотя в больших размерах Arial по-прежнему смотрелся лучше. Со временем, Verdana и Tahoma не раз подвергались критике со стороны дизайнеров. Оказалось, что Verdana не совсем корректно отображает некоторые знаки, у шрифта слишком тяжеловесное жирное начертание и не очень приятный курсив. А у Tahoma курсивного начертания не было вовсе, нередко буквы слипались между собой, что затрудняло чтение текста, а в крупных кеглях жирное начертание не выглядело достаточно жирным. К тому же на печати оба шрифта смотрелись далеко не идеально. Впрочем, эти нисколько не снизило популярность этих двух шрифтов в стане веб-дизайнеров до сих пор.
