Не удается подключиться к сети с хост-систем (гостевые системы работают)

Я собираюсь предположить, что "многие люди" в вопросе относятся к людям, пишущим учебники, руководства или ответы на -веб-сайтах, таких как этот.

При написании команд терминала в текстовом документе команда catобычно используется для отображения содержимого файла.

Пример этого:

$ cat script.sh
#!/bin/sh
echo 'hello'
$ chmod +x script.sh
$./script.sh
hello

Здесь я показываю, что у меня есть файл с именем script.sh, каково его содержимое, что я делаю его исполняемым, запускаю его и каков результат этого.

Использование catв этом примере является просто способом «показать все свои карты», т.е. явно отобразить все предпосылки для примера (и сделать это как часть текстового представления терминальной сессии ). ].

lessи другие экранные пейджеры, в зависимости от того, как они используются, не обязательно будут давать такой вывод в терминале. Итак, если бы я написал

$ less script.sh
#!/bin/sh
echo 'hello'

и пользователь попробовал это самостоятельно, они могут задаться вопросом, почему текст скрипта выглядит иначе в их терминале, а затем исчезает из терминала после закрытия lessпейджера (, если они так настроили пейджер ), или их lessотличается от less, используемого в ответе (, или учебнике, или чем-то еще ), или они делают что-то еще неправильно. Допущение возможности такого хода мыслей контрпродуктивно и разрушительно для пользователя.

Использование catпри отображении примера в терминале в виде текста хорошо, поскольку дает довольно простой способ воспроизведения точных тех же результатов, что и в данном тексте. Для больших файлов может быть лучше показать файл отдельно, а затем сосредоточиться на том, как этот файл используется при написании команды терминала в виде текста.

Если вы предпочитаете использовать less, more, most, view, sublimeили какой-либо другой пейджер или программу для просмотра файлов, это совершенно нормально. Иди и сделай это. Но если вы хотите предоставить воспроизводимый текст, описывающий какой-либо рабочий процесс в терминале, вам также придется предупредить пользователя о том, что вывод может отличаться между тем, что он читает, и тем, что он видит в своем собственном терминале, в зависимости от того, какой пейджер используется. и как он настроен.

1
01.01.2020, 06:49
1 ответ

Наконец-то я нашел решение. Кажется, это как-то связано с обновлением до bridge-utilsили, может быть, с ядром (, к сожалению, я не могу определить его конкретную версию/обновление ).

Поведение до заключалось в том, что мост автоматически использует MAC-адрес из интерфейса, поведение после обновления заключалось в том, что мост назначает случайно сгенерированный MAC-адрес (, который был заблокирован на стороне сети ).

После установки MAC-адреса моста(ip link set xenbr0 address 44:8a:5b:29:e6:40)доступ к сети снова работает, как ожидалось.

1
28.04.2021, 23:28

Теги

Похожие вопросы