С реализацией OpenBSD tcpwrappers
, Я думаю, что необходимо включать каждый из адресов в /etc/hosts.allow
, который, с 10k записями, очень скоро станет очень громоздким.
ALL : ... 78.128.49.0/24 78.128.50.0/24 ... : deny
Это не будет проводить много строк, прежде чем это станет кошмаром для управления. Обратите внимание, что адреса разделяются с пробелами или запятыми или обоими.
Если Вы имеете pf
настроенный и выполнение, Вы могли бы найти легче заполнить таблицу от содержания Вашего файла адреса:
table <blockthese> persist file /etc/list-of-addresses-to-block
block in log quick on $ext_if from <blockthese> to any
Поиски против таблиц в pf
быстры, и таблицы довольно эффективны с точки зрения использования памяти, поэтому если Вы действительно не ограничили суммы RAM на старой машине, это должно работать просто великолепно - это - стратегия, которую я использую на многочисленных хостах FreeBSD, и это работает очень хорошо.
Вы проверили файлы профилей?
~/.bashrc
~/.bash_profile
/etc/bashrc
/etc/profile
Предыдущий администратор мог оставить эту часть квоты
в качестве своего пользовательского имени входа в оболочку.
Нет причин обвинять только переменную LANGUAGE
. Во-первых, необходимо просмотреть выходные данные программы locale
и отметить, что существует много переменных, которые отвечают за разные вещи. Итак, если вы хотите получать английские сообщения изменить переменную LC _ MESSAGES
:
LC_MESSAGES=C type test
test is a shell builtin
type test
test встроена в оболочку
-121--73357- Использование различных ветвей является одним подходом, и я могу предложить правки для ответа @ mestia, если это кажется целесообразным (но читать на...).
Другой подход заключается в параллельном хранении различных файлов; Пример см. в Solaar .
Но оба эти подхода имеют существенный недостаток: они непригодны для пакетов в Debian или Ubuntu (или, возможно, других производных). Если вы намерены получить ваш пакет в дистрибутиве в какой-то день, вы должны упаковать его таким образом, чтобы один и тот же набор файлов дал правильный результат в различных дистрибутивах.
Для примера взгляните на пакет Debian для Solaar (полное раскрытие: Я сделал пакет).
Общая идея состоит в том, чтобы спросить dpkg-поставщика
, что такое распределение; таким образом, для Solaar, который имеет различные зависимости в Debian и Ubuntu, debian/rules
имеет
derives_from_ubuntu := $(shell (dpkg-vendor --derives-from Ubuntu && echo "yes") || echo "no")
и далее подавляет переопределение для dh _ gencontrol
, чтобы заполнить «substvars» в зависимости от обстоятельств:
override_dh_gencontrol:
ifeq ($(derives_from_ubuntu),yes)
dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme-full | oxygen-icon-theme-complete' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme-full
else
dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme | oxygen-icon-theme' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme
endif
Это заполняет соответствующие переменные в debian/control
:
Package: solaar
Architecture: all
Depends: ${misc:Depends}, ${debconf:Depends}, udev (>= 175), passwd | adduser,
${python:Depends}, python-pyudev (>= 0.13), python-gi (>= 3.2), gir1.2-gtk-3.0 (>= 3.4),
${solaar:Desktop-Icon-Theme}
и
Package: solaar-gnome3
Architecture: all
Section: gnome
Depends: ${misc:Depends}, solaar (= ${source:Version}),
gir1.2-appindicator3-0.1, gnome-shell (>= 3.4) | unity (>= 5.10),
${solaar:Gnome-Icon-Theme}
Вы можете использовать тест в debian/rules
для управления любым действием, которое вы можете выполнить в makefile, что означает, что вы можете объединить это с альтернативными файлами и, например, связать соответствующие файлы непосредственно перед их использованием в пакет построении.
Возможно, вы можете пойти с GIT-BuildPackage
и Держите различные каталоги Debian в разных филиалах.