Не удается открыть Google Chrome, не удается найти приложения в тире, запущенные приложения перестали работать

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

Я просто лизал эту проблему сам, и ответ для меня заключался в том, чтобы изменить следующую gdm.schema entry:

(original)
<schema>
      <key>greeter/IncludeAll</key>
      <signature>b</signature>
      <default>true</default>
    </schema>

(after my edit)
<schema>
      <key>greeter/IncludeAll</key>
      <signature>b</signature>
      <default>false</default>
    </schema>

Эффект от этого заключается в том, что вся информация о пользователях отключена, что, если я правильно интерпретирую исходный вопрос, на самом деле намеревается сделать OP (gruszczy). Это исключает необходимость создания длинной строки исключений, так как все идентификаторы пользователя, независимо от номера UID, исключаются независимо от того, будет ли изменен этот параметр. Я лично применил этот параметр к 3 отдельным серверам CentOS 6.2 на работе, которые иногда доступны через XDMCP (используя xrdp> vnc-server> xinetd> gdm> gnome) через RDP, что позволяет некоторым из наших менее опытных администраторов Linux работать над этими системы с минимальным обучением.

Все это говорит, хотя я согласен с тем, что неопытный системный администратор должен учиться с самого начала, чтобы работать с личной учетной записью (возможно, с доступом к суду), а не с правами root, если у вас есть опыт работы с этой учетной записью должным образом, нет никакого вреда в этом. Просто убедитесь, что вы знаете, что делаете перед вами. В случае с моими другими системными администраторами я добавил CentrifyDC для поддержки Active Directory ко всем этим системам и настроил системы, чтобы AD-UserID могли использоваться для сеансов рабочего стола при сохранении прав пользователя AD Security Group. Но лично, поскольку я разработал все эти серверы и использовал Linux уже более 15 лет, я не думаю, что использовать root для ускорения работы. Фактически, я стараюсь включить root в системах, где он был отключен, чтобы я мог использовать эту учетную запись и прервать погоню за тем, чтобы все было сделано. Главное, действительно, это просто создать привычку создавать резервную копию любого файла, прежде чем изменять его. Это будет безопасно защищать от большинства неудач и позволит вам восстановить систему, если вы выполните редактирование, которое в противном случае стало бы недоступным для системы (просто загрузитесь на Live CD и исправьте то, что нужно исправить).

ИМХО, я считаю, что мантра «никогда не входите в систему как корень» действительно существует, чтобы защитить системных администраторов n00bie от самих себя. Но если вы достигнете уровня компетентности с Linux до такой степени, что вы сможете инженеризовать систему из любой ОС Linux за очень короткое время, и она работает каждый раз, тогда нет причин жить по принципу «никогда не входить в систему как root», мантру, потому что к этому моменту вы готовы справиться с ответственностью, которая приходит вместе с использованием этой учетной записи. Это особенно справедливо в средах, которые используют поддержку CentrifyDC для AD, потому что «root» становится локальной учетной записью sysadmin и обычно (обычно) включается автоматически. Поэтому мне лучше всего перейти к преследованию и установить настройку пароля учетной записи root как одну из первых задач, которые я выполняю при любом развертывании в настоящее время. Конечно, я мог бы сделать весь вход в качестве своего собственного идентификатора, а затем sudo up, но я лично не чувствую необходимости делать что-то в этом роде. Ваш собственный пробег может меняться ...