Debian: репозиторий с «неправильным софтом»?

Я предполагал что ты что то про безопасность напишешь новенького.

Новенького? То есть, старенькое тебе уже не интересно?!

И дело не в объемах оперативки и вычислительной мощности процессоров. Не надо путать мух с котлетами и смешивать функциональность рабочей станции и сервера. Если, конечно, не хочется незабываемого нетрадиционного секса с упавшим в панику ядром из-за ошибки в видеодрайвере или подобного по фатальности сбоя.

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

на mirror-list глянул, что Южная/Центральная Америка вообще не представлена

https://www.archlinux.org/mirrors/

Brasil — 3 штуки, Чили — одна штука, Колумбия, Эквадор.

Brasil — 3 штуки, Чили — одна штука, Колумбия, Эквадор.

Виноват, не там посмотрел.

Спасибо за коммент. Нет, не ругали. Задачи такие, что можно экспериментировать, а может и нужно. Есть конечно вероятность, что всё «упадет», но есть и бекапы. Именно бекапы, многие на это забивают. А вообще так и не нашел вразумительного «за» и «против», всё на грани предрассудков.

Не надо путать мух с котлетами

Если говорить про это, то получается что? Бесперебойность можно гарантировать только отсутствием обновлений, но тогда получается что система будет «устаревать». И что такое обновление, это новшество которое может касаться и безопасности. То есть чем чаще я обновляю, тем система безопаснее, теоретически. Но обновление ядра и основных компонентов идет вразрез с бесперебойностью, всвязи с даже одним рестартом (сервисов, системы) то есть простой обеспечен на несколько секунд, минут. Или я не прав? Например интересуют системы которые обслуживают сотовую связь, там это категорично. Или ты обеспечил бесперебойность которая имеет возможность обновляться без рестартов? Ты уж поделись опытом если у тебя так?

Есть такая вот штука: https://www.ksplice.com/

Но её я не пробовал. Ещё вопрос апдейта можно решить кластеризацией (но я такую только на VMWare ESXi поднимал).

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

Ещё вопрос апдейта можно решить кластеризацией

а если «на пальцах» объяснять что оно делает, как это функционирует? высвобождает часть памяти и происходит замена области этой области? действительно работает?

это экспериментальная штука? или рабочее решение?

Какая именно? KSplice? Не в курсе, я слышал про неё, но не пробовал; можно почитать википедию на эту тему и сам сайт.

А кластеризация - конечно, рабочее; вот только не факт, что у тебя есть задачи под неё.

Есть ещё несколько вариантов недопущения простоев при апдейте. Лично я однажды делал так:
1) Копируем виртуальную машину;
2) Включаем её, предварительно поменяв ip сетевого интерфейса (как вариант - выключаем интерфейс, грузимся, меняем ip, включаем);
3) Одновременно в консоли vmware вырубаем сетевой интерфейс на «боевой» (либо меняем ip) и врубаем - на копии;
4) Спокойно проводим операции с боевой;
5) Копируем свежие появившиеся данные с копии на боевую;
6) Переключаем снова интерфейс;
7) Готово.

Нюансов тут много; данное решение актуально, к примеру, для lamp-сервера или для asterisk. Естественно, только если юзаешь виртуализацию.

а если «на пальцах» объяснять что оно делает, как это функционирует?

Не, кластеризация - это не то. Это работает так:

1) Поднимаем два сервера с БД (БД - как пример, ибо на них кластеризация чаще всего используется);
2) Настраиваем кластер (как - в двух словах не получится);
3) Теперь, если у тебя происходит что-то с одним из серверов, все задачи берёт на себя второй.

Это если ну совсем в двух словах.

У меня на прошлой работе был vmware-кластер; три сервака с >50 виртуальных машин. Даже в случае «смерти» двух из них всё продолжало работать, хотя и медленно.

Я с кластеризацией не сталкивался, но мне интересно. Правильно ли я понимаю:

1) основной сервер на котором есть виртуальные машины
2) виртуальные машины

всё что ты написал для операций замены касается второго пункта?

Да, но это не о кластеризации, о ней мой второй каммент. Это просто одно из возможных решений «на коленке», применимое для инфраструктуры виртуализации.

И да, ещё: если у тебя серьёзная инфраструктура, то у тебя не должно быть «основного сервера, на котором в том числе есть виртуальные машины». Сервер (называется гипервизор) должен содержать ТОЛЬКО виртуалки и никаких более задач; если есть другие задачи - значит, делаем ещё одну виртуалку и запихиваем их туда.

Поднимаем два сервера

два реальных сервера, то есть железных?

не должно быть «основного сервера

вот я об этом тоже задумывался, но сам момент переключения сетевого интерфейса на другой «сервер» ведь будет являться «перебоем» или это моментальная замена? а если запись в этот момент идет?

два реальных сервера, то есть железных?

Если это гипервизоры для виртуальных машин - тогда да; если нет - пофигу. Хочешь потренироваться - поставь две виртуалки, да и тренируйся. В продакшене тоже можно (а часто и нужно) виртуалки юзать.

у меня в принципе сейчас так реализовано, только я и так сказать «гипервизор» обновляю, а почему? потому как в нём ведь тоже со временем находят дыры в безопасности

сам момент переключения сетевого интерфейса на другой «сервер» ведь будет являться «перебоем»

Будет, но ничтожно малым по времени. Если это lamp-сервер, то от того, что сайт перестанет на доли секунды работать, ничего не случится.

а если запись в этот момент идет?

Потому я и написал, что это - вариант «на коленке», один из возможных. И применимый только для некоторых категорий задач. Я, например, так обновлял Asterisk, где потеря связи на доли секунды критична не была, а на несколько минут - была.

только я и так сказать «гипервизор» обновляю

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

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

Тебе выше уже замечательно ответили и про ksplice и про кластеризацию гипервизоров.

Downtime допустим, но должен быть строго регламентирован и как можно более коротким по времени, а не «моя левая пятка сегодня в обед зачесалась обновить всю инфраструктуру, потому мы теперь двое суток курим, ибо в апдейтах прилетело глючное ядро, которое грохнуло файловую систему на /var так, что fsck в авторежиме починить не может».

Обновления безопасности ДОЛЖНЫ ставиться максимально оперативно. Если необходим downtime - оповещаешь клиентов в процессе. Возможность таких факапов тоже должна быть регламентирована и клиент должен про неё знать.

А про бэкапы процитирую старую «хохму»: «Админы делятся на две группы - на тех, кто ЕЩЁ НЕ делает бэкапы и на тех, кто УЖЕ делает.»

Storage под виртуалки совсем отдельный был или тоже на vmware?

Storage под виртуалки совсем отдельный был или тоже на vmware?

Дисковая полка, конечно.

Ты ошибаешься. yaourt -Syua делает именно то, что тебе нужно.