Добавлю, что если используется initrd, то он найдёт корень по тому, что передано в параметрах ядра. И если там фиксированное имя устройства, а не UUID или LABEL, то фиг знает что может запустить.
С LABEL отдельная головная боль, одно время инсталляторы каких-то линуксов пытались монтировать систему после установки по LABEL=/, при двух системах возникала неоднозначность. Если уж его использовать, то каждой системе свой назначить командой e2label.
Алексей Юдов, список uuid можно получить командой blkid. Почему поменялся uuid не знаю, он вообще говоря при создании файловой системы инициализируется и не должен меняться просто так.
Вадим, в реальной ситуации порой приходится действовать даже ситуативно: к поду посреди ночи приходит OOM killer и надо срочно починить. Тем более что реально никто не знает специфику конкретного приложения. Может, ему в новогоднюю ночь на пять минут потребуется 5x памяти...
Тут граф из OSM, все дороги - ломанные линии с тэгами, указывающими класс дороги и развязки (на скриншоте красная дорога - highway=primary, ораньжевая - highway=secondary, рёбра развязки - highway=secondary_link), а также направление (все линии в OSM имеют ориентацию, если у дороги указать oneway=yes то дорога считается однонаправленной, что рендерится стрелочками).
В целом, если точности не хватает, точка может попасть на другую сторону дороги, на дублёр итд итп. Обычные навигационные программы избегают этого только благодаря предыстории - до этого машина уже ехала по конкретной дороге с конкретным направлением (если роутинговое ребро не двунаправленное). И предполагают, что машина следует указаниям навигатора, поэтому какое-то время навигатор может показывать движение по дороге, по которой машина уже не поехала.
Это не так-то просто, на самом деле. За комфортным и наглядным поведением навигатора стоят довольно сложные алгоритмы, которые отлаживались годами на реальной пользовательской базе. Тут нельзя за день-другой наваять не хуже.
WSGlebKavash, тогда курить настройку селинукса, или ваять правильные контексты, или автогенерацию осваивать (но она тоже не всегда надёжно работает). Ну и audit-логи учиться читать.
Григорий Рейн, надо для начала показывать ту самую "ожидаемую ошибку". И хорошо бы с куском кода, в котором было бы видно, где она возникает. В идеале - с минимально воспроизводимым примером.
А в такой форме ваще ничё не понятно и неясно что советовать.
Скорее всего из-за macvlan. Если при убирании этого контейнера (и сети соответствующей) всё чинится - вот и ответ.
При использовании macvlan следует перенести IP этого Linux с интерфейса (в данном случае ens160) на отдельный macvlan-интерфейс поверх него. Это решит, в частности, проблему с доступом с хоста в контейнер с macvlan - из-за особенностей macvlan это не работает вообще никак - в то время как между macvlan-интерфейсами всё есть (если bridge mode там включен).
Alkazavr, да, 100 рублей уже не копейки, если надо тысячу аккаунтов. Тем не менее, продающий нмера сервис не будет их держать вечно за одним клиентом и либо перепродаст ещё кому-то, либо освободит и вернёт оператору - а там возникнет потенциальная проблема с другим регистрирующимся в Телеграме.
Надёжнее всё же пойти купить свою симку, если нужно не терять аккаунт.
Alkazavr, например, номер из пула, который часто используется спамерами. Или после своей реги телеги кто-то ещё получает на сервисе тот же номер и ещё раз регает.
neostickerpack, соответственно, нужно выяснить, как этот сервер на localhost настроен. По идее, можно также его настроить под себя, создав на нём такую же зону с нужными себе записями.
У меня вон Mikrotik домашний сам себя в rDNS показывает:
$ host 10.7.8.1 10.7.8.1
Using domain server:
Name: 10.7.8.1
Address: 10.7.8.1#53
Aliases:
1.8.7.10.in-addr.arpa domain name pointer router.lan.
neostickerpack, нет, с ключом +trace это работает не так.
DNS - иерархическая система. Есть зона нулевого уровня . (точка), в ней домены первого уровня, в них домены второго уровня итд.
Обычный DNS-сервер без спецнастройки не знает никакого "DNS провайдера". Тем более что сам "DNS провайдера" как будет тогда работать? Можно поставить себе bind и посмотреть, как он устроен. Собственно, там идёт в поставке файл навроде root.named, в котором перечислены root-сервера. А дальше когда надо узнать xxx.yyy.zzz.com, то у рутсервера NS-запросом выясняется сервер зоны com, у следующего DNS-сервера выясняется сервер зоны zzz.com, итд итп. И зона arpa тоже не исключение. Ну это на пальцах, там есть тоже всякие нюансы.
DNS-сервер может принимать рекурсивные запросы, а может не принимать. В том числе часто настраивают так, что рекурсивные запросы принимаются лишь от доверенных адресов.
Например, пусть есть ns.company.com, у которого разрешены рекурсивные запросы сети 1.2.3.0/24, а остальным нет. При этом на этом сервере держатся зоны company.com и awesomeproduct.io. Тогда доверенным будут разрешены любые запросы, а сторонним - не все:
Благодаря этому все другие DNS-сервера и обычные клиенты с нерекурсивными запросами смогут получать домены компании, но не смогут использовать этот сервер как замену своего обычного DNS-сервера компании/провайдера/гугловосьмёрок/итд.
Что касается указанного случая, то тут обычно бы 192.168.2.3 не ресолвился бы вообще. Но похоже что используется DNS-сервер провайдера quantum.ru, а у него эта зона описана явным образом и возвращает какие-то адреса. При этом если у себя поменять DNS, например, на гугловые воьсмёрки 8.8.8.8, то этот IP перестанет распознаваться (*)
(*) но есть нюанс, некоторые провайдеры искусственно заворачивают "восьмёрки" на свой DNS. Но что мешает для проверки этого использовать DNS Яндекса 77.88.8.8, CF 1.1.1.1, quad9 9.9.9.9, opendns 208.67.222.222 итд итп?
С LABEL отдельная головная боль, одно время инсталляторы каких-то линуксов пытались монтировать систему после установки по LABEL=/, при двух системах возникала неоднозначность. Если уж его использовать, то каждой системе свой назначить командой e2label.