ответ на вопрос на 5:30 - sudo без тире не инициализирует окружение для user2 и соответственно file ищется в хоум директории текущего пользователя а не user2
Привет! Программа в графическом интерфейсе, с которой я работаю, называется эмулятор терминала Терминал это физическое оборудование, которое уже не используется. Но в целом для упрощения эмулятор терминала называют просто терминалом, да и любое место, где вводят команды, называют терминалом. Посмотри 5 урок (там говорится про эмулятор терминала и виртуальную консоль) Ну и на хабре есть интересная статья. Боюсь ссылку могут заблочить, поэтому просто погугли "Hello, World! Глубокое погружение в Терминалы"
Огромное спасибо! Прекрасно разложили! А можно пояснить про режимы или ссыль грамотную для почитать (интерактивный логин, неинтерактивный логин) и (интерактивный нонлогин, неинтерактивный нонлогин)
Условно, оболочку можно поделить на 2 "состояния" - оболочка со входом (login shell), оболочка без входа (non-login shell). При этом еще делятся на interactive и non-interactive. Когда осуществляется "логин" пользователя - там где вы вводите свой логин и пароль - будь то удалённо ( с помощью ssh ) или локально, зайдя, допустим, в виртуальный терминал или залогинившись в графическую оболочку, запускается .bash_profile. Это оболочка со входом (login shell). И раз уж вы логинитесь и запускаете команды - это interactive login shell. Когда же вы запускаете программу эмулятор терминала, то там нет логина, вы без логина и пароля можете вводить команды - оболочка без входа (non-login shell). При этом, в эмуляторе терминала работаете вы - этот interactive non-login shell. Когда работают скрипты, они обычно запускаются без всякого логина - тут уже non-interactive non-login shell. Да, когда вы запускаете эмулятор терминала, в этом эмуляторе запускается bash. И при этом, при запуске, он запускает .bashrc. Сами по себе .bashrc и .bash_profile - это просто набор команд в одном файле. То есть это скрипты. Когда же вы логинитесь (не важно каким образом), тоже запускается bash, при этом он запускает .bash_profile
Первой командой su user2 -c "touch file" - мы пытаемся от имени пользователя "user2" создать файл в каталоге пользователя "user1", но т.к. небыла произведена авторизация и небыл прочитан файл .bash_profile пользователя "user2" а был прочитан лишь ".bashrc" и мы фактически остались в каталоге пользователя "user1" что не дает нам право создавать файлы в данном каталоге, за исключением, если вы не "root" тогда можно будет. А во втором случае командой su - user2 -c "touch file", мы сначало считываем содержимое ".bash_profile" пользователя "user2" в котором указан путь до домашнего каталога "user2" и автоматически логинится в домашний каталог "user2" и уже в нем создает файл "file" . P/S: это был мой поток мыслей... Просьба поправлять меня если я не прав, т.к. я только учусь и если ничего не понятно тоже пишите попробую переформулировать более кратко. Спасибо автору за материал!
В целом идея правильная - в первом случае мы остались в каталоге первого пользователя, где у нас нет прав создавать от имени второго пользователя. Во втором случае файл создаётся в домашней директории второго пользователя. Но есть пара замечаний - во первых, при touch file мы нигде не указали путь до домашней директории (то есть переменная HOME тут не участвует) - мы используем текущую директорию, т.е. попробуйте вместо touch file ввести команду pwd. Во вторых, некоторые переменные, например HOME, не задаются в каких-то файлах, а генерируются какими-то программами. Допустим, когда вы логинитесь в систему, срабатывает программа login, которая берёт значение для переменной HOME в файле /etc/passwd.
так же на ~7:40 я так понимаю что sudo запускает команду не от имени суперпользователя а с правами суперпользователя, т.к. что бы запустить каманду от имени нужно написать $ su "имя пользователя"" -с "команда" P.S. тысячу извенений автору, я просто пытаюсь освоить материал...)
Не совсем, sudo тоже запускает от процессы от имени - "sudo, sudoedit - execute a command as another user". Просто "запускать от имени суперпользователя" или "запускать с правами суперпользователя" - одно и тоже. Можете проверить, запустив команду sleep 30 как с помощью su (su - user -c "sleep 30"), так и с помощью sudo (sudo -u user sleep 20"), а потом сделать ps -ef | grep sleep и посмотреть, кто владелец процесса (в обоих случаях это будет user)
На моей системе home директория по умолчанию не создалась. Но если запустить adduser с ключом -m то должна создать. Или для уже созданного пользователя получилось добавить директорию через mkhomedir_helper.
У меня закрылось подозрение, что .d - это некий формат перезаиси фала настроект. Если есть файл с именем file, то в директории file.d система будет искать файл изменяющий его частично или полностью. Это как-то так устроено, подпись .d? Возможно в следующих видео разбирается этот вопрос?
Не, суть в другом Предположим, есть какой-то сервис - daemon и у него есть конфиг - /etc/daemon.conf Так вот, иногда конфиг файл должен содержать много чего разного. Ну прям тонну информации. И эти настройки можно разделить на кусочки - тут у нас настройки юзеров, тут настройки ещё чего-то, тут ещё чего-то. Ну например, в профилях пользователя могут быть настройки как баша, так и всякие языковые настройки, настройки цветов, алиасов и т.д. и т.п. И вместо того, чтобы держать всё вместе в одном большом файле, логичнее разделить конфиг на множество файлов. А где размещать все эти куски конфига? Правильно, в /etc/daemon.d/. Т.е. директория, где лежат настройки. А в основном файле (/etc/daemon.cond) обычно есть ссылка, указывающая, что нужно искать продолжение конфига здесь, обычно это что-то вроде "include /etc/daemon.d/*.conf". Ну и ещё так бывает удобно добавлять и удалять какие-то настройки. Вместо того, чтобы заходить в файл и редактировать какие-то строчки, которые фиг пойми на какой строчке и как выглядят, легче просто заменить готовый файл. Скажем хочешь заменить цветовую схему - просто берёшь готовый файл настроек и заменяешь им старый.
провел небольшой тест с очередностью загрузки login-shell В файлы загрузки записал строку echo "путь к текущему фалу ->" >> /home/user/filelog Вот что вышло: /etc/profile.d/freetype - > /etc/profile.d/gawk - > /etc/profile.d/home-local.sh - > /etc/profile.d/locale - > /etc/profile - > ~/.bashrc - > bash_profile не получается запустить, даже если строку ставлю в самое начало - она по видимому не срабатывает. /etc/bashrc тоже не засветился
/etc/profile - > идет после profile.d потому что я вставил строку в коце фйала после всего скрипта а вот вместо /etc/bashrc видимо используется /etc/bash.bashrs
@@babichfx название файлов может отличаться на дистрибутивах. Где-то это bashrc, где-то bash.bashrc. Где-то это .profile, где-то .bash_profile Там логика в следующем - в середине /etc/profile указано считывать настройки из profile.d, он сразу заходит туда и начинает по алфавиту запускать файлы. А потом и сам заканчивается
Это относится к графическому интерфейсу, к утилите XDG user directories. Когда пользователь логинится через графический интерфейс, запускается утилита xdg-user-dirs-update и создаёт директории согласно файлу /etc/xdg/user-dirs.defaults или $HOME/.config/user-dirs.dirs. Чуть больше об этом: wiki.archlinux.org/index.php/XDG_user_directories_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)
хаха "безопасность строится на полном недоверии друг к другу"
ответ на вопрос на 5:30 - sudo без тире не инициализирует окружение для user2 и соответственно file ищется в хоум директории текущего пользователя а не user2
верно
Здравствуйте!
Спасибо большое! Подскажите, чем отличается эмулятор терминала от обычного терминала и в чем Вы работаете на уроке? Я немного запутался)
Привет!
Программа в графическом интерфейсе, с которой я работаю, называется эмулятор терминала
Терминал это физическое оборудование, которое уже не используется. Но в целом для упрощения эмулятор терминала называют просто терминалом, да и любое место, где вводят команды, называют терминалом.
Посмотри 5 урок (там говорится про эмулятор терминала и виртуальную консоль)
Ну и на хабре есть интересная статья. Боюсь ссылку могут заблочить, поэтому просто погугли "Hello, World! Глубокое погружение в Терминалы"
@@GNULinuxPro, спасибо большое!
Огромное спасибо! Прекрасно разложили! А можно пояснить про режимы или ссыль грамотную для почитать (интерактивный логин, неинтерактивный логин) и (интерактивный нонлогин, неинтерактивный нонлогин)
Условно, оболочку можно поделить на 2 "состояния" - оболочка со входом (login shell), оболочка без входа (non-login shell).
При этом еще делятся на interactive и non-interactive.
Когда осуществляется "логин" пользователя - там где вы вводите свой логин и пароль - будь то удалённо ( с помощью ssh ) или локально, зайдя, допустим, в виртуальный терминал или залогинившись в графическую оболочку, запускается .bash_profile. Это оболочка со входом (login shell). И раз уж вы логинитесь и запускаете команды - это interactive login shell.
Когда же вы запускаете программу эмулятор терминала, то там нет логина, вы без логина и пароля можете вводить команды - оболочка без входа (non-login shell). При этом, в эмуляторе терминала работаете вы - этот interactive non-login shell.
Когда работают скрипты, они обычно запускаются без всякого логина - тут уже non-interactive non-login shell.
Да, когда вы запускаете эмулятор терминала, в этом эмуляторе запускается bash. И при этом, при запуске, он запускает .bashrc. Сами по себе .bashrc и .bash_profile - это просто набор команд в одном файле. То есть это скрипты.
Когда же вы логинитесь (не важно каким образом), тоже запускается bash, при этом он запускает .bash_profile
@@GNULinuxPro, спасибо за Ваш труд!
не обязательно делать закрыть-открыть терминал, можно перечитать rc-файл командой source (source ~/.zshrc for zch)
Первой командой
su user2 -c "touch file" - мы пытаемся от имени пользователя "user2" создать файл в каталоге пользователя "user1", но т.к. небыла произведена авторизация и небыл прочитан файл .bash_profile пользователя "user2" а был прочитан лишь ".bashrc" и мы фактически остались в каталоге пользователя "user1" что не дает нам право создавать файлы в данном каталоге, за исключением, если вы не "root" тогда можно будет.
А во втором случае командой su - user2 -c "touch file", мы сначало считываем содержимое ".bash_profile" пользователя "user2" в котором указан путь до домашнего каталога "user2" и автоматически логинится в домашний каталог "user2" и уже в нем создает файл "file" .
P/S: это был мой поток мыслей...
Просьба поправлять меня если я не прав, т.к. я только учусь и если ничего не понятно тоже пишите попробую переформулировать более кратко.
Спасибо автору за материал!
В целом идея правильная - в первом случае мы остались в каталоге первого пользователя, где у нас нет прав создавать от имени второго пользователя. Во втором случае файл создаётся в домашней директории второго пользователя. Но есть пара замечаний - во первых, при touch file мы нигде не указали путь до домашней директории (то есть переменная HOME тут не участвует) - мы используем текущую директорию, т.е. попробуйте вместо touch file ввести команду pwd. Во вторых, некоторые переменные, например HOME, не задаются в каких-то файлах, а генерируются какими-то программами. Допустим, когда вы логинитесь в систему, срабатывает программа login, которая берёт значение для переменной HOME в файле /etc/passwd.
Спасибо! )
так же на ~7:40 я так понимаю что sudo запускает команду не от имени суперпользователя а с правами суперпользователя, т.к. что бы запустить каманду от имени нужно написать $
su "имя пользователя"" -с "команда"
P.S. тысячу извенений автору, я просто пытаюсь освоить материал...)
Не совсем, sudo тоже запускает от процессы от имени - "sudo, sudoedit - execute a command as another user". Просто "запускать от имени суперпользователя" или "запускать с правами суперпользователя" - одно и тоже. Можете проверить, запустив команду sleep 30 как с помощью su (su - user -c "sleep 30"), так и с помощью sudo (sudo -u user sleep 20"), а потом сделать ps -ef | grep sleep и посмотреть, кто владелец процесса (в обоих случаях это будет user)
На моей системе home директория по умолчанию не создалась. Но если запустить adduser с ключом -m то должна создать. Или для уже созданного пользователя получилось добавить директорию через mkhomedir_helper.
Это будет в 19 части. Хотя про mkhomedir_helper впервые слышу =)
У меня закрылось подозрение, что .d - это некий формат перезаиси фала настроект. Если есть файл с именем file, то в директории file.d система будет искать файл изменяющий его частично или полностью. Это как-то так устроено, подпись .d? Возможно в следующих видео разбирается этот вопрос?
Не, суть в другом
Предположим, есть какой-то сервис - daemon и у него есть конфиг - /etc/daemon.conf
Так вот, иногда конфиг файл должен содержать много чего разного. Ну прям тонну информации. И эти настройки можно разделить на кусочки - тут у нас настройки юзеров, тут настройки ещё чего-то, тут ещё чего-то. Ну например, в профилях пользователя могут быть настройки как баша, так и всякие языковые настройки, настройки цветов, алиасов и т.д. и т.п. И вместо того, чтобы держать всё вместе в одном большом файле, логичнее разделить конфиг на множество файлов. А где размещать все эти куски конфига? Правильно, в /etc/daemon.d/. Т.е. директория, где лежат настройки. А в основном файле (/etc/daemon.cond) обычно есть ссылка, указывающая, что нужно искать продолжение конфига здесь, обычно это что-то вроде "include /etc/daemon.d/*.conf".
Ну и ещё так бывает удобно добавлять и удалять какие-то настройки. Вместо того, чтобы заходить в файл и редактировать какие-то строчки, которые фиг пойми на какой строчке и как выглядят, легче просто заменить готовый файл. Скажем хочешь заменить цветовую схему - просто берёшь готовый файл настроек и заменяешь им старый.
Господи, как же круто!
Конечно мало ещё знаю, но все кажется так классно продумано!
провел небольшой тест с очередностью загрузки login-shell
В файлы загрузки записал строку echo "путь к текущему фалу ->" >> /home/user/filelog
Вот что вышло:
/etc/profile.d/freetype - >
/etc/profile.d/gawk - >
/etc/profile.d/home-local.sh - >
/etc/profile.d/locale - >
/etc/profile - >
~/.bashrc - >
bash_profile не получается запустить, даже если строку ставлю в самое начало - она по видимому не срабатывает.
/etc/bashrc тоже не засветился
/etc/profile - > идет после profile.d потому что я вставил строку в коце фйала после всего скрипта
а вот вместо /etc/bashrc видимо используется /etc/bash.bashrs
@@babichfx название файлов может отличаться на дистрибутивах. Где-то это bashrc, где-то bash.bashrc. Где-то это .profile, где-то .bash_profile
Там логика в следующем - в середине /etc/profile указано считывать настройки из profile.d, он сразу заходит туда и начинает по алфавиту запускать файлы. А потом и сам заканчивается
@@GNULinuxPro да, bash.bashrc я кстати оттуда взял)
Почему при создании нового пользователя у него нет домашних директорий? (Documents, Music и т д)
Это относится к графическому интерфейсу, к утилите XDG user directories. Когда пользователь логинится через графический интерфейс, запускается утилита xdg-user-dirs-update и создаёт директории согласно файлу /etc/xdg/user-dirs.defaults или $HOME/.config/user-dirs.dirs.
Чуть больше об этом:
wiki.archlinux.org/index.php/XDG_user_directories_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)
А почему при запуске рута и при попытке открыть sudoerc там отображается пустой файл, а когда открываешь через sudo то он заполнен?
Может вы не тот файл открываете? файл /etc/sudoers
От рута тоже можно запустить visudo
@@GNULinuxPro АААА сорри, я тупой, миллион извинений за такой вопрос.
Да ладно, всё нормально, с кем не бывает?)
А какая операционная система однопользовательская, школол?