Архив форумов ЦИТФорума

[Valera]

ОС: Freebsd 4.5 Система обновлялась.
Есть такая проблема: под давно зарегистрированным в системе пользователем (с правом использования рутовых прав) начались непонятки. Пытаюсь ставить программу - глючит. Ставит ее другой юзер (недавно зарегистрированный) - все ок.
Например, поставил я midc со встроенным редактором, так если я теперь пытаюсь редактировать файл, выскакивает "ошибка записи файла". И только после нажатия энтера пускает редактировать файл. Если зайти под другим пользователем - все ок, такого не выдает.
Пытался поставить (из портов) mysql - выдал ошибку при компиляции. От другого юзера нормально скомпилился.
В чем это может быть дело, народ? Куда мне копать, чтобы решить проблему?
Можно удалить этого юзера, или сделать его только почтовым юзером, но выход ли это?

[anthony]

-

[Valera]

Глюки как раз с пользователем, который в нулевой группе. Других я завожу в других группах.

[Dmitry.Karpov http://www.]

Простейший способ - поискать имя этого юзера во всех файлах в директории /etc :
grep юзер /etc/*

PS: Людям, которые слабо разбираются в системе, настоятельно советую не обновлять систему, а ставить с форматированием разделов / и /usr, хоть AlexanderK меня за это и ругает.

[Valera]

Обновлять систему помогал гуру.

[Dmitry.Karpov http://www.]

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

[Dmitry.Karpov http://www.]

Как я где-то слышал, процесс обновления заменяет исполняемые файлы, но не файлы конфигурации - иначе бы он повредил сделанные админом настройки. Но если в новой системе "умолчальные" конф.файлы отличаются от старых (может поменяться даже формат файла), то последствия непредсказуемы. Я сам столкнулся с файлом pam.conf при переходе с 4.2 на 4.4 - пришлось заменить вручную.

[Valera]

Не затрагивает - это точно.
Но есть специальная утилитка mergemaster, которая сравнивает новые и старые конфигурационные файлы. И в момент выполнения этой программы можно или оставить старый, или заменить новым конф. файлом.
Конечно, есть риск, что чего то упустишь, что то потеряешь.

[Dmitry.Karpov http://www.]

Общий алгоритм:
- зайти в директорию /etc;
- найти все файлы с датами момента формирования дистрибутива (обычно и много, и они самые древние);
- заменить их на файлы с теми же именами из директории /etc/upgrade;
- посмотреть остальные файлы - не изменился ли там формат записей.

[Valera]

Вот, что получается: удаление и заведение юзера заново ни к чему не приводит. Но выяснилось следующее: если юзер не в wheel группе, то все ок, никаких глюков, как только перевожу его туда - тут же все по старому начинается.
Фигня какая то с группой wheel у меня выходит..

[Dmitry.Karpov http://www.]

В Unix можно выставить атрибуты доступа типа rwx---rwx - в этом случае полный доступ есть у хозяина файла, а также у всех остальных, кроме входящих в группу, которой принадлежит файл (а можно выставлять не полный доступ, а как-нибудь иначе). Возможно, надо поискать файлы, у которых "остальным" дается больше прав доступа, чем "группе" - это умеет делать команда 'find' с ее многочисленными ключами-аргументами. Высока вероятность, что вышесказанное относится к файлу в директории /etc .

[Valera]

У некоторых еще бит выполнения стоит и все

[Dmitry.Karpov http://www.]

В /etc есть файлы, которые ни в коем случе нельзя давать на чтение посторонним - например, master.passwd и spwd.db.

Если не нашел в /etc - ищи по всему диску.
Посмотри логи на момент регистрации юзера и на момент отказа в каком-нибудь доступе.
Еще имеет смысл покопаться в /etc/group на предмет замены цифры ноль на букву "O".