Що за дивина з root?

[ussr1k]

блін, я в консолі і лажу тільки під рутом:)) убунту 7,04

[miwa]

Ніхто не сказав, що так робити неможливо. Але ніхто не казав також, що так варто робити.

[ussr1k]

а як ти вважаєш шо краще юзати кожен раз судо???
а так раз під рутом залогінився і все. і нема проблем:))
от тільки потім як якусь прогу запустити від користувача потрібно буде, то прийдеться або запустити ше один термінал, або виходити з-під  рута...

[Praporshic]

А що заважає отримати рута через sudo?

[noddeat]

а як ти вважаєш шо краще юзати кожен раз судо???
а так раз під рутом залогінився і все. і нема проблем:))

sudo bash - і маєте термінал під рутом.
sudo xterm  - X - термінал під рутом, відповідно
Не треба нікуди логінитись

[Praporshic]

sudo bash - і маєте термінал під рутом.
sudo xterm  - X - термінал під рутом, відповідно
Не треба нікуди логінитись

Ще коротше: sudo -s
В обох випадках.

[miwa]

а як ти вважаєш шо краще юзати кожен раз судо???

Так.

[Володимир Лісівка]

sudo bash - і маєте термінал під рутом.
sudo xterm  - X - термінал під рутом, відповідно
Не треба нікуди логінитись

Ще коротше: sudo -s
В обох випадках.

Краще робити "sudo -i" або (для старішої версії) "sudo su -" - тоді правильно будуть встановленні змінні такі як PATH, HOME, що дозволить уникнути типової проблеми коли програма під рутом щось пише в $HOME як root. після чого та ж програма відмовляється писати в той же файл під звичайним користувачем. Хоча не буде скопійоване значення змінної DISPLAY і X-ові програми не зможуть знайти $HOME/.xauth.

[Praporshic]

Мені в цьому плані треба навпаки: там де я працюю від рута я працюю _ЛИШЕ_ від рута.
Більш того, в мене свої вподобання, в шефа (що теж працює лише від рута) - інші. Завдяки саме -s кожен отримує свій набір змінних $EDITOR та подібних.

[noddeat]

так і є, щось не можу собі уявити програми, яку треба запускати і під рутом, і під звичайним юзером

[Praporshic]

В мене усі програми треба запускати або під рутом, або під звичайним юзером. На серверах - лише під рутом. На десктопі - лише від користувача.

[borman]

Постійно працювати під root? Та це ж збочення! Втім, це лікується. Першою ж опечаткою типу rm -rf / tmp/mydir.

Лінивці зазвичай додають себе до групи wheel і пишуть в файл /etc/pam.d/su рядок auth sufficient pam_wheel.so trust. Після чого насолоджуються роботою su без пароля.

Причина відмови реєстрації root з консолі теж банальна -- це заборонено (не дозволено) в файлі /etc/securetty. До якого в свою чергу звертається PAM під час обробки файлу /etc/pam.d/login.

[Praporshic]

Постійно працювати під root? Та це ж збочення! Втім, це лікується. Першою ж опечаткою типу rm -rf / tmp/mydir.

Питання у відповідь: як Ви адмініструєте сервер? Від звичайного користувача? Взагалі, як можна працювати під звичайним користувачем, коли усі можливі діє може виконати лише root? Та й взагалі, не постійно - спочатку потрапляю на ssh як звичайний користувач, а потім вже sudo -s.

Лінивці зазвичай додають себе до групи wheel і пишуть в файл /etc/pam.d/su рядок auth sufficient pam_wheel.so trust. Після чого насолоджуються роботою su без пароля.

Оце вже збочення. В мене ssh по ключам та sudo через пароль. Виходить досить зручно.

Причина відмови реєстрації root з консолі теж банальна -- це заборонено (не дозволено) в файлі /etc/securetty. До якого в свою чергу звертається PAM під час обробки файлу /etc/pam.d/login.

[borman]

Для левової частки дій під час адміністрування будь-якої системи наявність прав рута зовсім не є обов'язковою умовою. Більш того, є навіть небажаною умовою з огляду на вимоги безпеки. Звісно, хтось на це звертає більше уваги, хтось -- менше.

Вищенаведений приклад стосувався системи в якій доволі часто виникає потреба перемикатися між рутом та звичайним користувачем. Особисто для мене -- це десктоп. В цьому випадку зручність на першому місці, і su без пароля виглядає набагато доречніше ніж sudo+<ще_якийсь_там_пароль>.

Звісно, від ssh-ключів ніхто не відмовляється. Проте можливість автоматичного (я ж так розумію passphrase не використовуєте) входу на сервер під користувачем без обмеження набору команд (з /bin/bash в /etc/passwd) -- це потенціальна дірка і при певному рівні вимог до безпеки системи за це слід надавати по рогах. Використання ssh-ключів -- це вибухонебезпечна розкіш, а ви використовуєте їх на сервері. Схоже, у нас різні погляди на термін "збочення"

[Praporshic]

Для левової частки дій під час адміністрування будь-якої системи наявність прав рута зовсім не є обов'язковою умовою. Більш того, є навіть небажаною умовою з огляду на вимоги безпеки. Звісно, хтось на це звертає більше уваги, хтось -- менше.

Якщо врахувати, що система ніколи не лишається без нагляду, а після виконання конкретної роботи робиться logout, то жодних проблем з безпекою. Небажано - так, але інакше неможливо. Така та FreeBSD бяка...

Вищенаведений приклад стосувався системи в якій доволі часто виникає потреба перемикатися між рутом та звичайним користувачем. Особисто для мене -- це десктоп. В цьому випадку зручність на першому місці, і su без пароля виглядає набагато доречніше ніж sudo+<ще_якийсь_там_пароль>.

На своєму ноуті (десктопа не маю) останній раз заходив під рутом десь з тиждень тому, коли мало не поклав систему форковою бомбою власного виробництва.

Звісно, від ssh-ключів ніхто не відмовляється. Проте можливість автоматичного (я ж так розумію passphrase не використовуєте) входу на сервер під користувачем без обмеження набору команд (з /bin/bash в /etc/passwd) -- це потенціальна дірка і при певному рівні вимог до безпеки системи за це слід надавати по рогах. Використання ssh-ключів -- це вибухонебезпечна розкіш, а ви використовуєте їх на сервері. Схоже, у нас різні погляди на термін "збочення"

Для початку треба ще ім'я користувача вгадати, це перше. По друге, щоб увійти в систему, де є ті ключі теж треба логін та пароль вгадати. Залишається єдиний варіант - LiveCD. Але треба ще на біос пароль вгадати, або встановити диск у інший комп або ноут. Та й навіть отримання шел доступу до безправного користувача через ключ ще не надає можливості щось зробити - треба знати пароль щоб зробити sudo або su.