Обычно строка типа
:map g :w
имеет литеральное ^M
окончание, чтобы позволить пользователю завершить команду карты без нажатия Enter.
Если .vimrc
достаточно короткий, например, состоит всего из нескольких строк, где большинство имеют окончания ^M
, vim догадается, что файл использует окончания DOS (возврат каретки / перевод строки), и будет хранить обновления в файле, используя это соглашение - на протяжении всего времени.
Для дальнейшего чтения
Файл . vimrc
похож на любой другой текстовый файл: vim угадает его окончания строк при чтении. На самом деле, вы должны быть в состоянии сделать файл, содержащий два ^M в конце исходного файла: (1) для завершения команды map
, и (1) для завершения строк.
Я решил эту проблему сам, надеюсь, кому-то это будет полезно. Я просмотрел ошибки ~/.xsession -, они содержали:
(imsettings-check:16467): IMSettings-WARNING **: 04:42:56.491: Could not connect: Connection refused
(imsettings-check:16467): GLib-GIO-CRITICAL **: 04:42:56.491: g_dbus_proxy_call_sync_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed
GLib-GIO-Message: 04:42:56.807: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications.
** (process:16260): WARNING **: 04:42:56.824: Could not make bus activated clients aware of XDG_CURRENT_DESKTOP=GNOME environment variable: Could not connect: Connection refused
а затем я погуглил первопричину, установка miniconda нарушила PATH в файле.bashrc, я удалил эту строку, и она была исправлена :
export PATH="/home/stiv/miniconda3/bin:$PATH"
ОБНОВЛЕНИЕ:Позже я нашел x2go , который работает намного надежнее и быстрее, чем XRDP.
sudo apt-get update
sudo apt install xrdp
sudo apt-get install xserver-xorg-core
sudo apt-get install xorgxrdp
nano /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf
Скопируйте приведенный ниже polkit в02-allow-colord.conf
polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.color-manager.create-device" || action.id == "org.freedesktop.color-manager.create-profile" || action.id == "org.freedesktop.color-manager.delete-device" || action.id == "org.freedesktop.color-manager.delete-profile" || action.id == "org.freedesktop.color-manager.modify-device" || action.id == "org.freedesktop.color-manager.modify-profile") && subject.isInGroup("{group}"))
{
return polkit.Result.YES;
}
});
sudo ufw allow 3389/tcp
sudo /etc/init.d/xrdp restart
sudo systemctl status xrdp
sudo systemctl enable xrdp
Выйдите из сеанса.
Попробуйте через RDP
Учетная запись пользователя, с которой вы пытаетесь это сделать, является членом группы sudo
или wheel
? В версии Kali 2020 любой пользователь, не являющийся частью sudo
, немедленно отключится, мне пришлось убить все процессы этого пользователя (pkill -u <username>
), а затем удалить учетную запись пользователя и создать ее заново. Я все еще отслеживаю точную причину, почему это происходит, когда у меня есть время. Но решил поделиться своим опытом.
Попробуйте это:
Остановить xrdp командойsudo service xrdp stop
Отредактируйте сценарий запуска xrdp :sudo nano /etc/xrdp/startwm.sh
В этом файле заменить строки
test -x /etc/X11/Xsession && exec /etc/X11/Xsession
exec /bin/sh /etc/X11/Xsession
сstartxfce4
(Вы можете закомментировать строки, добавив #
в начале)
Перезапустите xrdp с помощьюsudo service xrdp start
Выберите Xrdp в качестве сеанса и войдите в систему.
Я столкнулся с этой проблемой, пытаясь подключиться к рабочей машине, на которой запущен xrdp на Red Hat Enterprise Linux 7. Я установил miniconda и datalad в их базовой среде в моей домашней папке на удаленной машине, и это сломало удаленный рабочий стол Windows. Решение оказалось на удивление простым. Я удалил даталад и переустановил его в новой среде через SSH. Затем я смог без проблем снова подключиться к машине через удаленный рабочий стол Windows.
Необходимо выполнить следующие дополнительные действия:
Чтобы настроить Xrdp, сначала добавьте
exec gnome-session
в конец файла конфигурации
/etc/xrdp/xrdp.ini
Или используйте следующую команду, чтобы добавить «сессию exec gnome -» в конец файла конфигурации «/etc/xrdp/xrdp.ini»
sudo bash -c 'echo "exec gnome-session" >> /etc/xrdp/xrdp.ini'
Перезапустите xrdp, чтобы загрузить новую конфигурацию
sudo systemctl restart xrdp
За последние несколько лет я провел много дней с периодически возникающими проблемами доступа к серверу Linux с ПК с Windows 10. Различные подходы к модификации Server xrdp.ini, похоже, решают проблему, но не навсегда. После сбоя со свежими установками RHEL8 и Centos8, все сбои с входом в систему RDP на ПК, я заметил следующую распространенную ошибку. После сбоя с ПК ошибка, наблюдаемая при «полу» успешном повторном -входе в систему с того же ПК, наблюдалась в systemctl status xrdp
, где представлен список неудачных элементов. Однако при наблюдении непосредственно на самом сервере с помощью экрана, клавиатуры и мыши (у меня есть Dell R430 рядом со мной ), systemctl status xrdp
выглядит чистым, без проблем. Каждый новый вход в RDP с помощью Xvnc, по-видимому, запускает отдельный сеанс/процесс rdp. Я пришел к выводу, что проблема связана с ПК и каким-то образом сбоем SSL. Он сохраняется на ПК, пока он не перезагрузится. Сервер не требует перезагрузки. Конечно, ПЕРЕЗАГРУЖАТЬ ПК нецелесообразно, но многократно успешно.