E: The method driver /usr/lib/apt/methods/https could not be found.
N: Is the package apt-transport-https installed?
7. Updating repository ... failed.
Еще вопрос — какие сейчас делаются движения (делаются ли, и какие перспективы) чтобы полностью поддерживать весь функционал опенвз на современных ядрах, без привязки в рхел7?
По объективным причинам (пример — NVMe) много людей хочет иметь более свежее ядро, пусть даже с чуть меньшей стабильностью. При этом остаться без venet, как это можно сейчас — не вариант.
У меня не возникает понимания в процессе чтения этой рассылки. Может, конечно, это я такой глупый )
Но вот возьмем nvme. В рассылке мне ответили, что для него желательно 3.19+. VZ7 конечно ни разу не 3.19+, но вдруг там всё бекпортировано? Я начал смотреть в репозиторий, но не смог разобраться.
Про zfs, на сколько я помню, обещания очень переменчивы. В багтрекере есть предложение использовать какой-то готовый внешний слой абстракции, который позволит всё, но не ясен статус этой идеи, не ясно когда оно будет, если будет, и не ясно что будет с квотами.
Про квоты и simfs обещания так же переменчивые. Особенно про second level user quotas.
У меня X220 и до какого-то одного из последних обновлений биоса он вполне так регулярно падал в синий экран после длительной нагрузки (две планки по 8 памяти, сотни открытых табов в браузере + танчики)
> проверять все DNS доменов на наличие в них наименования провайдера
Это несколько неправильно. Например, у нас есть домены с нс серверами в старом домене knutov.net и в новом после ребрендинга много лет назад dobrohost.ru. И есть еще два домена с нс серверами, относящимися к нашим вдс, совсем в других доменах. С 1stat можно было отправить список нс серверов и потом всё группировалось правильно.
(был бы проект на перле — я бы дописал нужную функциональность, но увы).
Мы тоже очень расстроены текущим состоянием 1stat. Пожелание — группировать нс сервера провайдеров, автоматически и с возможностью вручную передать список своих серверов (например, у нас — они в непохожих разных доменах).
Весь смысл фб2 изначально был именно в том, что у нас есть исходник с разметкой в фб2, есть правила как это должно выглядеть на конкретном девайсе с конкретным разрешением, и дальше из фб2 по правилам рендерится под девайс и его формат.
епаб — это конечный формат. фб2 — это промежуточный исходник, из которого делается любой конечный формат под любой девайс и разрешение. Почему-то все это забывают.
Во времена наладонников благодаря чудесным читалкам у многих сложилось восприятие фб2 как конечного формата (и для некоторых платформ/читалок это может быть так), но это ошибочное восприятие.
Там же по задумке было — делаем книгу один раз в фб2, рендерим из фб2 под любой девайс и любой формат. Доживших до наших дней альтернатив я не знаю ни одной.
в интернетах пишут, что на RHEL 6 уязвимость не работает, хотя формально и есть.
А когда будет сам подкаст?
А еще оно не умеет определять venet интерфейсы внутри опенвз.
После установки на паре вдс на опенвз — решил поставить на саму ноду. На что установщик мне радостно сделал
В реальности он правда ничего не постопил и вроде всё как было запущено — так и осталось.
Вопрос — зачем оно использует вообще ps вместо пид файлов?
Не очень понятно почему — делалось то всё под рутом.
У нас используется hidepid=2 (и это нельзя изменить). Если это оно мешает — может как-то можно вручную помочь?
Это понятно. Непонятно, почему оно само его не ставит, раз надо.
Просто так, кстати, не ставится, приходится использовать --force-yes
apt-get install -y --force-yes apt-transport-httpsПоставить вручную помогло
Еще вопрос — какие сейчас делаются движения (делаются ли, и какие перспективы) чтобы полностью поддерживать весь функционал опенвз на современных ядрах, без привязки в рхел7?
По объективным причинам (пример — NVMe) много людей хочет иметь более свежее ядро, пусть даже с чуть меньшей стабильностью. При этом остаться без venet, как это можно сейчас — не вариант.
У меня не возникает понимания в процессе чтения этой рассылки. Может, конечно, это я такой глупый )
Но вот возьмем nvme. В рассылке мне ответили, что для него желательно 3.19+. VZ7 конечно ни разу не 3.19+, но вдруг там всё бекпортировано? Я начал смотреть в репозиторий, но не смог разобраться.
Про zfs, на сколько я помню, обещания очень переменчивы. В багтрекере есть предложение использовать какой-то готовый внешний слой абстракции, который позволит всё, но не ясен статус этой идеи, не ясно когда оно будет, если будет, и не ясно что будет с квотами.
Про квоты и simfs обещания так же переменчивые. Особенно про second level user quotas.
Про zram и zswap вообще давно никто не вспоминал.
Вопросы то те же, что были всегда:
Или они большие, но сидят в хетзнере, умеют его готовить и им всё ок.
Проблема смены ип адреса при переезде — не так чтобы проблема, а иногда и не проблема вовсе.
Некоторым хостингам на определенной стадии может потребоваться собственная AS.
В общем, с позиции топ20 как оно там у более мелких, наверное, уже не очень хорошо видно, да и просто не интересно, но не надо так категорично.
Вообще неправильная идея. Например, у нас нет своей AS и не появится прежде, чем в ней будет реальная необходимость. И таких — большинство.
Идея дать мне интерфейс — хорошая. Время для ручных правок есть )
При этом — дипхост находится по слову bz8, и показывается как bz8.ru.
Определенно, нужна табличка соответствия названия провайдера и списка его нс серверов.
Это несколько неправильно. Например, у нас есть домены с нс серверами в старом домене knutov.net и в новом после ребрендинга много лет назад dobrohost.ru. И есть еще два домена с нс серверами, относящимися к нашим вдс, совсем в других доменах. С 1stat можно было отправить список нс серверов и потом всё группировалось правильно.
(был бы проект на перле — я бы дописал нужную функциональность, но увы).
Мы тоже очень расстроены текущим состоянием 1stat. Пожелание — группировать нс сервера провайдеров, автоматически и с возможностью вручную передать список своих серверов (например, у нас — они в непохожих разных доменах).
Весь смысл фб2 изначально был именно в том, что у нас есть исходник с разметкой в фб2, есть правила как это должно выглядеть на конкретном девайсе с конкретным разрешением, и дальше из фб2 по правилам рендерится под девайс и его формат.
Во времена наладонников благодаря чудесным читалкам у многих сложилось восприятие фб2 как конечного формата (и для некоторых платформ/читалок это может быть так), но это ошибочное восприятие.
Там же по задумке было — делаем книгу один раз в фб2, рендерим из фб2 под любой девайс и любой формат. Доживших до наших дней альтернатив я не знаю ни одной.